[cap-talk] [Apparmor-dev] Re: Directory Fd's and designation

[Mark Seaborn]

"Rob Meijer" <capibara at xs4all.nl> wrote:

> On Thu, November 22, 2007 20:37, Mark Seaborn wrote:
> > "Rob Meijer" <capibara at xs4all.nl> wrote:
> >
> >> * 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.
> >
> > The question is, what programs will do this?  No existing programs use
> > directory FDs this way, so I assume we are talking about new code.
> 
> About minor changes to existing code. A lot of programs take directory
> paths as arguments. Changing the paths to dirFd's and the non *at calls to
> *at calls would make it trivial for the abouve to be used.
> The posibility to thus use the abouve is somathing that has major value in
> for example computer forensic applications.

That's not a minor change, that's a major change, because there is so
much code that uses pathnames.  That's not to say I think it is a bad
idea to do a refactoring like that.  It is a good idea, but if you are
going to do it, you may as well change code to use new library calls
that provide a more abstract interface than kernel FDs, rather than
changing code from one syscall to another.


> > The ways in which you might want to limit access directories are
> > almost limitless and it would be more extensible to implement that by
> > proxying in user space rather than trying to pick a set of permission
> > bits for directory FDs to be implementeed by the kernel.
> 
> I agree that would have much added value, but in my view Fd passing would
> be ideal as a basis for this.
> I would imagine that communicating Fd's with a Fuse user space filesystem
> in the described maner would yield the wanted results that you would want
> for Plash, but with the aded bonus that using only the Fd based permission
> transfer would be a simple way to 'fix' existing programs into working
> under POLA constraints without the need for the userspace overhead.

Using Plash with FUSE in a fine-grained way is not a simple
proposition.  FUSE is not a capability-style system.  As far as I
know, a FUSE filesystem can't choose to implement only the directory
structure while leaving the files themselves to another filesystem
implementation.  I don't think FUSE operates in terms of FDs.  That
means that implementing a mount table with FUSE would involve proxying
all file accesses through the user space FUSE process, whereas with
Plash, only directory tree operations need to be proxied.

If you want to move commonly-used directory wrapper objects into the
kernel after finding they are too slow in user space that would make
sense.  Jed Donnelley has described NLTSS as working in that way,
allowing filesystems to be placed in the kernel or user space, using
the same interfaces in both cases.  But implementing it all in-kernel
to start with seems like premature optimisation.

Regards,
Mark