[cap-talk] Directory Fd's and designation (was: Object Capabilities for AppArmor)

[Rob Meijer]

Given that aparently the discussion is non existent at the moment, it may
be a good thing to split up the basic ideas and discuss them seperately.

The first and most pressin issue being the use of directory Fd's.

The point with directory Fd's is that unlike file or network Fd's they
don't actualy convey any permissions/authority.
My proposal was to create a system call (using procfs or sysfs) for a
linux security module that ads a bitmap to the directory Fd tthat could be
seen as describing the authority caried by the dirFd.

Now that's for the easy part. Currently the LSM hooks don't seem to provide
a way to find out what Fd was designated in any of the at* system calls,
or even if an at* system call was used at al.

For this, IMO work should be done to get hooks into the LSM framework so
that the task structure's security information would be allowed hold
information on the currently designated Fd(s) from within any other
relevant hook.

To make a bit clearer what the goal of all this would be, a litle example
of its potential use:

* Process A runs with all the permissions/authority of user a, or all
  permissions defined by the a program AppArmor profile.
* Process A creates /home/a/work/input, and writes some files into it.
* Process A creates /home/a/work/output
* Process A opens a Fd for both directories, sets apropriate mask bits so
  the first designates read only access, and the second designates that
  new files can be created , but no new directories.
* Process A defines that its next child should run starved from any access
  permissions.
* Process A starts up process B handing it the two directory Fd's.
* Process B can use the at* system calls with the directory Fd's,
  it can now read all files in the input dir, and write result files
  into the output dir, but does not have access to any other permission
  that process A or user/program a did.

I feel that if the aditional hooks could go into the LSM framework, the
rest of the implementation of this feature into an LSM (preferably
AppArmor)  would be close to trivial, and would be very usefull.
I feel also that it and AppArmor would be fully complementary.

I'll be posting some more messages on other less crucial parts of my
draft. That is, user level ambient capabilities, cross user/profile
delegation and Fd based system calls. As to me it seems more easy to get a
discussion going on the seperate issues seperately.

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