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

[Crispin Cowan]

John Johansen wrote:
> On Thu, Jan 18, 2007 at 09:36:28AM +0100, Anniyka Wandersmann wrote:
>   
>> 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 :)
>   
Well put :)

> - 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.
>   
This is an interesting case, and we have some design flexibility. Note
that my previous post suggested that we do close-on-exec by default, and
leave-open on exec if a specific novel capability was present. We can do
the same thing with hats:

    * hats are generally introduced by apparmor-aware code to confine
      another program that doesn't even know it is executing in a
      context, so default FDs are not a problem, we can aggressively
      close them on entering and leaving the hat.
    * cases where that won't do can put the leave-open capability in the
      hat. since it is something you put in a hat, call it a feather :)

However, because the outer domain code is going to expect to keep its
files open through the execution of the hat code, we can't really close
them just because of a change_hat(). Instead we would have to mediate
access, i.e. check reads & writes to see if the files is in the hat's
access list.

That, in turn, means we need revalidation again :( Perhaps in this case
it would be best to use the hack of caching the original file name
instead of working hard to recover the current file name. I don't like
it, but if the revalidation code that uses the current name isn't viable
for LKML, then I can live with it.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hacking is exploiting the gap between "intent" and "implementation"