[cap-talk] User level ambient capabilities (Was Object Capabilities for AppArmor)

[Rob Meijer]

Next to the more coherent use of directory Fd's, it would be interesting
to discuss the Fd based user level ambient capabilities I proposed.

Where POSIX capabilities as implemented in Linux are concerned with
permissions that normaly belong with usage by root, that normal users
should normaly not posses, you could use a simular mechanism for
permissions that a normal user or AppArmor controled program does have,
but that in theory a normal process spawned by this user should normaly
not have. If you take it to the extreme you could say that most system
calls
that do not involve the usage of permissions designated by Fd's should be
considdered priviledged to a user or (apparmor profile defined) program
spawned process.
If we could define a set of ambient capabilities along the line of the
POSIX ambient capability bitmap as currently used in Linux, but at this
described level, this could be very usefull IMO.

In order to facilitate the ease of delegation that the OC model advocates
I further proposed that the natural vehicel for these ambient capabilities
would be an Fd.

Basically there would be two ways how this could be implemented.

1) Using a /dev/null Fd and adding a system call for clearing out
   the apropriate ambient capability bits.
2) By defining a procfs or sysfs hierarchy, and making sure that Fd's
   opend from this hierarchy hold the appopriate ambient capability bit(s).

My view is that it wouldn't hurt to implement both, starting of with 1 as
it would be much simpler to implement.

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
>
>