[Apparmor-dev] Object Capabilities for AppArmor

Crispin Cowan crispin at mercenarylinux.com
Thu Nov 22 03:09:06 MST 2007 

Rob Meijer wrote:
> I've tried to process your, Peter and and Mark's feedback and just placed
> a revised version of my first draft on http://polacanthus.net/fdoc.html
>
> I've attempted to clearify some points that I understood to be unclear
> from feedback I got, and tried to make modifications from your usefull input.
>   
I've been trying to digest the whole document, but that's taking too
long, so instead I'll address what I see as issues.

Rob says that he does not want to implement any kind of "do not
(re)delegate authority" options. Here I disagree.

The issue is that one of the ways that FDs can be delegated is to leave
them open across exec(). Lots of software legitimately does this. OTOH,
lots of software accidentally does this, and that has lead to at least
half a dozen security vulnerability issues in the last 2 years. An
attacker can thus coax a privileged program into exec'ing something the
attacker controls, leaving some sensitive FDs open, and thus gain access
to those FDs.

So I see it as essential for AppArmor to have a switch of some kind to
determine whether FDs are delegable.

Rob, why do you think it is important that there not be policy controls
to permit delegation?

There's lots of choice here about what the switch controls:

    * It could control all delegation, or only FDs left open on exec.
          o I favor the general case of allowing or denying all
            delegation, because it is simpler, and I don't see a case
            for the added complexity of differentiating between passing
            FDs by exec and passing them via sockets.
    * It could be profile-wide, or it could be per-rule, e.g. add a 'd'
      permission specifying that access to a file is delegable.
          o Again, I favor profile-wide "can delegate" just because I
            prefer simple in the absence of a pressing need for complexity.
    * Delegation could be allowed by default and denied by policy, or
      denied by default and allowed by policy.
          o I favor denied by default and allowed by policy, because
            that is how AA does everything else.

Applying my usual litmus test to myself "Is it learnable?" it can be
made learnable, but it is tricky: With the profile in learning mode, you
would have to detect that the FD is actually used by a child. Or a grand
child. Or a great-great-great ..... great grand child. If the FD is ever
used before it ultimately dies with a process that doesn't delegate it
before exit(), then the profile rule should allow delegation, and
otherwise not.

Implementing learning for that is possible, but difficult. For instance,
perhaps it would work to add a "delegated by <profile name>" tag to an
open FD when it is delegated, and if it is ever used again, then log
that the delegating profile should be permitted to delegate this FD.

Problem: if it is delegated more than once, e.g. delegated through more
than one profile, then you end up with a *list* of profiles that are
delegating the FD, all of which need to be marked to allow this/any
delegation.

The learning mode for this being challenging, I can see a case for just
building a policy mechanism that allows you to manually write a policy
for delegation, even if it cannot be learned right away. Even so, the AA
tools would need to be updated to at least understand and respect the
policy language for delegation, even if we do not yet fully implement
learning.

Crispin

> I hope the updated doc will help in the discussion.
>
> I currently have aproximately 300 hours planned for work on this over the
> next 10 to 13 months, either as a seperate LSM module or as a part of
> AppArmor (including the time I'll need to get up to speed with kernel
> development and AppArmor specifics).
>
> I'll be abel to be on the irc channel sunday anywhere from 12:00 till
> 17:00 or anywhere from 19:00 till 23:00 localtime (I'm on GMT+1).
>
> Rob
>
>
> On Sat, November 17, 2007 20:18, Crispin Cowan wrote:
>   
>> From various discussions in these mailing lists, I have recently moved
>> from on-the-fence to inclined in favor of adding some Object
>> Capabilities to the AppArmor system. However, because of the UNIX
>> legacy, and the way that AppArmor is intended to work, it cannot be a
>> pure OC system, it will have to be some kind of a hybrid. I particularly
>> like the file descriptor OC hybrid that Rob Meijer has proposed, but
>> will need some refinement.
>>
>> For example, in UNIX file descriptors are left open on exec(), unless
>> you do something to close them. Sometimes software deliberately leaves
>> file descriptors open as a parameter passing technique, but there is
>> also a chronic sequence of security vulnerabilities where FDs are
>> unintentionally left open. Thus AppArmor needs some kind of policy
>> mechanism to specify whether FDs should be left open on exec() in
>> particular circumstances.
>>
>> To figure out just how to do this, I propose a discussion on the
>> apparmor-dev mailing list (where the reply-to: is pointed) and a virtual
>> conference in the #apparmor IRC room. American Thanks Giving holiday is
>> coming, so I propose approximately a week's discussion, and a virtual
>> conference in #apparmor on Sunday November 25th. The exact date & time
>> of the virtual conference can be determined in follow-ups to this post
>> on apparmor-dev.
>>
>> Please join this discussion if you are interested. apparmor-dev holds
>> non-member posts for moderation by a human. The human policy is to
>> filter spam only, but if you want your posts to go straight through
>> unmoderated, please subscribe to apparmor-dev, it is not a high volume
>> list. Well, it wasn't until just now :)
>>
>> Thanks,
>>     Crispin
>>
>> --
>> Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
>> CEO, Mercenary Linux		   http://mercenarylinux.com/
>> 	       Itanium. Vista. GPLv3. Complexity at work
>>
>> _______________________________________________
>> Apparmor-dev mailing list
>> Apparmor-dev at forge.novell.com
>> http://forge.novell.com/mailman/listinfo/apparmor-dev
>>
>>
>>     
>
>
> _______________________________________________
> Apparmor-dev mailing list
> Apparmor-dev at forge.novell.com
> http://forge.novell.com/mailman/listinfo/apparmor-dev
>
>   

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work

More information about the Apparmor-dev mailing list