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

Thu Nov 22 05:46:28 EST 2007

I have a more meta-level question.

>From what I understand, you propose using file descriptors (FDs) as
capabilities. FDs may be passed via UNIX domain sockets etc. and thereby
make for a useful capability analogue. 

However, I noticed in your design docs that you propose using a special
interface in /proc in order to communicate with the FdOC LSM module.

> In order to communicate between user space processes and server space
> security modules, the security modules must (?) use read and write actions on
> the /proc/self/attr/current pseudo file.

If this is the case, then why not use this interface for capability
passing as well and roll your own capability tokens (akin to FDs but not
actual FDs themselves) that are managed solely by the FdOC module.

For example, you might use small ints, as in the case of FDs. Each
process initially has a cap to itself (0). When forking a child via
FdOC, a process can obtain a cap to it via some (as yet unspecified)
protocol with /proc/self/attr/current. Say this cap-to-child is
allocated the next index (1). It could then, for example, send cap 0
(that points to itself) to the child, by "invoking" cap 1 via
the /proc/self/attr/current interface. The child can receive incoming
messages by invoking *its* cap 0 via /proc/self/attr/current, thereby
receiving the cap to its parent etc.

By rolling your own caps and using your own cap-invocation interface,
you can attach whatever data you need to the
(in-kernel-representation-of) the capabilities, such as permission masks
or other info, without having to worry about breaking existing
intra-kernel interfaces. 

Although this does of course mean you get no backwards compatibility
with existing POLA-aware code that uses file-descriptor passing as an
approximation to caps.

Just a thought.

On Thu, 2007-11-22 at 10:19 +0100, Rob Meijer wrote:
> 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
> >
> >
> 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk