[cap-talk] Cross user/profile delegation (Was: Object Capabilities for AppArmor)

[Rob Meijer]

An interesting issue with respect to Fd based delegation of permissions
in any form comes at the point where two models colide.

LSM is build to be used purely restrictive, so communication of permissions
between for example processes running by different uid's could result
in unexpected restrictions.
In the same way standard Fd communication is purely permissive, thus
Fd's could be passed between processes who's programs have different
AppArmor profiles, possibly also resulting in unexpected behaviour from
the profile view.

Given that the mariage of LSM and FdOC, and possibly AppArmor would result
in an hybrid model, there comes the question of how to handle the hybidity
between different users and/or different AppArmor profiles.

My first instinct would say: 'try to avoid the unexpected'.

To me this would come down to the folowing:

* Block all IPC between users to avoid the unexpected behaviour.
* Block all IPC between AppArmor confined programs that do not share
  some 'namespace' label.

A second road could be to put a lot of efford in documented the
behaviour and restrictions of the abouve situations.

I am very interested to learn what others think on this subject.

Rob

On Sun, November 18, 2007 22:31, 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 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
>
>