[apparmor] private-file and private-files-strict abstractions (Was Re: [PATCH] abstractions/private-files updates for shells)

Tue Apr 19 10:47:35 UTC 2011

On Mon, 2011-04-18 at 12:09 -0700, Steve Beattie wrote:
> On Mon, Apr 18, 2011 at 09:03:49AM -0500, Jamie Strandboge wrote:
> > Bug #761217[1] came in to add several zsh files to the private-files
> > abstraction. This patch does that and adds a few others (with light
> > refactoring) after reading the manpages for dash, bash, zsh, csh, tcsh
> > and pdksh.
> 
> Are you nominating this for 2.6?
> 
I did not, but I think it is worthwhile.

> Also, I haven't followed the development of the private-files and
> private-files-strict abstractions closely; that said, I'm mildly
> dubious of preventing read access to bashrc et alia in private-files
> rather than private-files-strict; I think it might make it less usable
> for ssh-force-command types of behaviors where a script might be the
> only thing allowed to be invoked and backstopped by apparmor.
> 
> I guess I'd like to see the reasoning behind why something should go
> into one or the other.

In this particular case, I added the shells to private-files because
bash was already there, but the reason why bash is there is explained
below.

History and intent
------------------
Why private-files* exist at all is to help profilers confine certain
types of applications in a general manner such that we can say this:
 * the application is not allowed to execute arbitrary code (ie,
standard 'default deny' AppArmor profiling)
 * the application is generally allowed to read things in $HOME, since
that is the nature of its design (eg we actually want 'owner @{HOME}/**
rw,')
 * the application should not be able to read from sensitive files (eg,
password stores) or write to files that could lead to arbitrary code
execution (eg shell initialization files or autostart directories).

Obviously, a profiler can choose to use the abstractions in ways that
don't use the above criteria. The intent of the private-files*
abstractions is to make it possible to create a profile with a default
deny stance on code execution (everywhere) and data access outside of
@{HOME} and default allow stance for data access in @{HOME} that we own.
This default allow for data access is not as secure of course and
creates an arms race, but it does allow for easier profile creation and
maintenance of access to potentially dangerous files (eg, having it in
an abstraction means we as an upstream can push out updates that affect
everyone rather than admins all doing it by themselves individually).
While imperfect (due to the arms race nature), it is IMO still valuable.
AFAIK, currently the private-files* abstractions are only used in
Ubuntu.

private-files-strict is intended to be used in situations that meet the
above criteria, such as:
profile /usr/bin/foo {
  #include <abstractions/private-files-strict>

  /usr/bin/bar ix,

  owner @{HOME}/ r,
  owner @{HOME}/** r,
}

private-files-strict includes private-files, and the private-files*
abstractions typically use 'deny' without audit for denying reading of
common files to help avoid log spam. They use 'audit deny' when the
application is clearly doing something wrong (eg, a write to
~/.bashrc). 

Splitsville
-----------
So, why the split between private-files and private-files-strict? In two
words: bug #451422[1]. With AppArmor, you cannot override an explicit
'deny' rule with an allow rule. I originally wanted to only have one
private-files abstraction and put things like 'deny @{HOME}/.mozilla/**
mrwkl,' in it, but ran into situations like evince needing access to
firefox' Cache directory (for reading PDFs) but not wanting to give
access to all of ~/.mozilla to evince. Another case is when trying to
confine firefox, which needs access to all of ~/.mozilla, but shouldn't
have write access to ~/.bashrc. A concrete example is for evince I would
like to use something like this:
profile /usr/bin/evince { 
  ...
  #include <abstractions/private-files-unified>
  owner @{HOME}/.mozilla/**/*Cache/* r,
}

but alas, I cannot (private-files-unified here is supposed to be all of
private-files and private-files-strict).

So what is in private-files-strict? Simply put, what can't blindly be
put in private-files, which is entire application directories for
major/widely-used applications that contain password stores or similar.
The following are currently in private-files-strict:
 * .gnupg/
 * .ssh/
 * .gnome2_private/
 * .mozilla/
 * .config/chromium/
 * .{,mozilla-}thunderbird/
 * .evolution/
 * .config/evolution/
 * .kde/share/apps/kmail/
 * .kde/share/apps/kwallet/

This file is intentionally kept small because while a profiler should
always strive to use private-files-strict, if he/she is profiling an
application that needs access to one of the items in
private-files-strict, then use private-files and copy/paste the other
items from private-files-strict that you don't need access to in your
profile. What is in there now is based in part on the historical needs
of profiling evince and firefox (eg, evince needed access to firefox'
cache directory, and firefox needed access to gnupg for encrypted
webmail, so these could not be put in privte-files). This split is
highly suboptimal for a lot of reasons. Some are:
 * it is confusing
 * we don't have protection from lesser used applications like
sylpheed-claws or opera
 * copy/paste is a maintenance nightmare
 * we can't profile in a manner that is intuitive (ie, allowing access
to something that was denied via a general explicit deny rule)
 * profilers must understand the split, especially if using only
private-files
 * what is put in private-files-strict is fairly arbitrary
 * ...

The split was created at a time when it was thought that bug #451422
would be fixed, and therefore the split was supposed to be temporary
(indeed the evince profile in Ubuntu still references this bug).

Thankfully, many times we don't need to use private-files* at all since
reads and writes by applications don't need such wide access, or we can
use file extensions or other means for confinement. For other
applications like image/video/audio/... previewers, file managers, and
things that don't store passwords, we can simply use
private-files-strict. Since bug #451422 isn't going to be fixed any time
soon, I am very open to other suggestions on how to improve the
private-files* split.

Thanks

[1]https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/451422

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20110419/2cbc13ff/attachment-0001.pgp>