[Apparmor-general] Moving To A Pure Capability Model?

[John Johansen]

On Thu, Jan 18, 2007 at 09:36:28AM +0100, Anniyka Wandersmann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi there,
> 
> as long, as I can do the following, I do follow AppArmore wherever it 
> leads ;)
> 
> - - leave untouched or increase the level of security
> 
it will leave the level of security untounched, increase it or decrease it
depending on your point of view :)

Going with a pure capability model makes it easier for profiled applications
to interact and communiticate.  This has several effects:
- It will make your profiles more generic because the profile will not
  have to list every file it touches.
- It makes your profiles more secure because they don't have to have a
  huge list of files that are need only sometimes.
  - ie the profile is tighter because it only list what the program needs
    as long as the other files are passed into it.  Security is increased
    because you don't have to list in the profile all the files that could
    be passed in, thus for any given instance the application has fewer
    files it can touch.
- It makes your profiles less secure because you can not control which
  files are being passed between applications.  Whats more is unix does
  not close open files on exec by default so any file that is accidentally
  left open can now be accessed.
- It makes your profiles less secure because it diminishes the value of
  changehat.  The hats only restriction is on what new files can be
  opened.  It has access to all files opened by its parent, and
  the parent also gets access to all files opened by the hat.
- It makes little to no difference from an information flow point of
  view because in current AA if app A can access a file it can still
  pass the file data to app B even if they don't share files through
  an IPC mechanism.
  Of course from a pragmatic pov shutdown some paths of communications
  is still more secure than none.

> - - I want, as it's already noted, read a profile in text and do understand 
>   what's going on. Leave this simplicity untouched. The more complex, the 
>   more holes can be left open by error.
> 
true but would you support having the ability to be more expressive if
it was optional and didn't change the simplicity if not used.  Either
way being able to use a text editor to view/edit policy is important.

> - - make better dokumentation or easier configuration behaviour on 
>   change-hat. I don't get it till now ... perhaps it's easy but I do not 
>   understand the Documentation or it's not that easy... '
>   (or I am to dump on it. ;)
> 
yep the documentation needs to be improved.  Changehat itself is both simple
and complicated at the same time.  The basic concept of changehat is
simple, switch a running program into a seperate profile for a given
period of execution.  The switching to a different hat means that the
policy for an application can be split based off of what the programs
needs are in a given phase.  Ie Startup, event loop, priveledge seperation,
sub program all have different access requirements and to make security
better its best if each phase gets the minimum access privledges needed.

Where changehat becomes complicated is in the actual semantics and
implementation.  To use changehat in apparmor you need 2 things
an application that has been modified so that it can call into the
changehat api, and a profile with hats (subprofiles) defined.

The program must be modified because there is no generic way to detect
when an application is moving from one phase of execution to its
next.  When the application is modified it is given a list of hat names
to try in order of preference, or in the case of mod_changehat it
will generate hat names based of urls etc.

The application presents the "list" of names to the apparmor module in
order of preference, and the module will switch the applications
profile to the first hat that matches.  The application when it hits
another privledge transition point call into changehat again either
returning to its parent profile or changing to another hat.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-general/attachments/20070122/50fa1a99/attachment.pgp