[Apparmor-dev] Re: AppArmor Security Goal

[John Johansen]

On Mon, Nov 12, 2007 at 08:56:16PM +0100, Christian Boltz wrote:
> Hello,
> 
> Am Sonntag, 11. November 2007 schrieb John Johansen:
> > On Sat, Nov 10, 2007 at 03:52:31PM -0800, david at lang.hm wrote:
> > > On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
> > >   is there a wildcard replacement for username? so that you could
> > > grant permission to /home/$user/.mozilla...... and grant each user
> > > access to only their own stuff?
> 
> > A variable no.  But the current iteration does allow specifying
> > permissions for files that are owned by the user.  The method to do
> > so has been changed from the current posting and may change again as
> > their is some debate as to how best express this.
> >
> > So system policy can express something similar by doing
> >
> > owner rw @{HOME}/.mozilla,
> 
> I see the "owner" keyword the first time. Just curious:
> - Is it already supported in openSUSE 10.3?
No, the code existed pre 10.3 but the feature was and to some extent still
is being debated.

The most recent posting to lkml contained the feature but in a slightly
different form.  The permissions were expressed as a user:group:other
triple similar to dac.  So you could express

   owner rw @{HOME}/.mozilla,
 as
   rw:: @{HOME}/.mozilla,

 standard AppArmor rules were still supported and internally mapped
 to the triple, ie.

   rw /foo,

  would become

   rw:rw:rw /foo,

There are some difficulties however with allowing mediation based off
of the group and some people really didn't like the U:G:O triple
syntax so the group portion has been pulled and the syntax dropped in
favor of a "simpler" keyword.  Well at least for the time being.

I am preparing a road map and feature document that I will post out
to apparmor-dev for further discussion on this and other features.

> - Is it mentioned in the documentation?
No.  Neither is the reverse permission syntax I used above, though that
one did make it into the 10.3 parser.  It was not mentioned because
the tools (genprof, logprof) don't support it.

The option of using that syntax is being added as it has been requested
several times.

> - How is the owner detected? User ID of the confined process?
>   Or on other ways?

Yes the fsuid of the confined process is checked against the uid of
the file.  This allows bypassing the whole issue of trying to keep
kernel side uid to username mapping in sync with changes made
user side.

It is also more flexible than using a variable because it can be used
to seperate access to user files in shared directories.  It also allows
for a few other behaviors that are very desirable.  You can specify
an openwall link style restriction by using

  owner l /**,

basically this only allows creation of hard links to files the process
owns.

There are also a couple of other features that went out with the
most recent lkml posting that didn't go into 10.3

pix, link pairs, and profile namespaces.

In short:

- pix is a profile or inherit mode which will use a profile if present
  but if not instead of failing the exec will fall back to inheriting
  the current profile.

- link pairs allow specifying tighter link restrictions by specifying
  both the source and destination

  link /foo -> /bar,

  traditional link rules map as
    rwl /linkname,
  to
    rwl /linkname -> /**,

  the perms are important as traditional link perm forces a perm subset
  test.

- profile namespace provide a way to have multiple sets of profiles
  loaded.  This is useful for roles or containerizing vservers,
  which each role or vserver would get its own profile set.
  The feature is very rudimentary at the moment and only accessible
  through the change_profile feature at the moment.

  The plan is to update pamarmor so that it can be used to put users
  into different roles.


If you want to play with the owner perms or any of the other features
under 10.3 it is possible.  I have been planning on building some packages
and putting them up for people to play with, with the caveat that they are
not supported by log/genprof at this time.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-dev/attachments/20071112/afa9b68b/attachment.pgp