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

[Crispin Cowan]

Daniel de Kok wrote:
> On Fri, 12 Jan 2007, Crispin Cowan wrote:
>> Our options going forward are:
>>
>>    * Completely remove all revalidation, producing the pure capability
>>      model discussed previously in this thread.
>
> One of the things I like about AppArmor is its clarity - it is pretty
> easy to see just be reading a profile what is going on. I think moving
> to this pure capability model adds to this clarity.
Ok, that's one more vote for pure capabilities.

Some of the inside AppArmor developers have expressed a desire to see
revalidation retained. Is there anyone in the user community who wants
it? I have not encountered such yet.

>>     * Close all open FDs on exec by default
>>     * Provide an extended capability (smells just like a POSIX.1e
>> capability, but named "pass_fd_on_exec" or such like) that if enabled
>> restores the classic behavior
>>     * similar capability for closing the special stdio FDs
> I don't know anything about AppArmor internals, so I may be suggesting
> something that is not really feasible or plain dumb :). But what about:
>
> * Close all open FDs on exec by default
> * Allow the administrator to use a flag in a profile exec rule that does
>   not force this default behavior.
Hmmm, you are correct: whether to leave FDs open on exec is a function
of *two* identities: the profile exec'ing, and the profile being exec'd to.

> As far as I can see there are two advantages: it allows for more
> fine-grained access control on execs, and it doesn't require adding a
> new capability to programs that want to pass their fd's.
What Daniel is suggesting is an additional flavor of x permission. We
currently have:

    * Px and px: transition to a new profile, where Px securely cleans
      the environment variables, and px leave the environment intact.
    * ix: child inherits same profile as parent, and thus no environment
      scrubbing is necessary.
    * Ux: child executes unconfined. There is no 'ux' because it is
      insecure, allowing a confined parent to force an unconfined child
      to access any file through fun with libraries.

Rather than add to the plethora of flavors of x, it seems to me that
Daniel's idea fits best with Px and px: that Px should close FDs on
exec, and px should leave FDs alone, just as with environment variables.
ix should leave FDs alone, and Ux should close them.

How does that sound? So if you want pure capabilities, use px, and if
you want revalidation, use Px. The ix and Ux rules are just implicit to
the level of trust for inherit and unconfined execution.

Thanks Daniel. I really like this now :)

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"