Re: [RFC PATCHv2 00/11] Adding FreeBSD's Capsicum security framework

On Jul 29, 2014 11:25 PM, "Eric W. Biederman" [off-list ref] wrote:

I have cut this down to just focus on O_BENEATH openat case.

David Drysdale [off-list ref] writes:

quoted

On Mon, Jul 28, 2014 at 10:13 PM, Eric W. Biederman
[off-list ref] wrote:

quoted

quoted

Nope.  What you can implement today if you want fine grained limitations
like this is to create a mount namespace with exactly the subdirectory
tree you want to allow access to and to return a file descriptor that
points into that mount namespace.  (When complete the only user of that
mount namespace would be your file descriptor).

How does that solve the particular example I mentioned?  The DFD
within the mount namespace will still allow any operation on any file
that's already in the subdirectory -- or am I misunderstanding
something?

The goal was to bound the DFD to the directory and all of it's
subdirectories such that openat(dfd, "../../..") would open
the dfd, and that further opens of other directories would also not
allow you to escape.

Since the mount namespace only contains the choosen directory and it's
subdirectories that works easily and trivially.

So while you can indeed perform any file operation on that dfd who
cares because none of those operations can get you anywhere you aren't
supposed to be.

My point was that you can as granular as you would like by binding a dfd
to a mount namespace instead of binding a process to a mount namespace,
and the code already exists and is being maintained.

So while things are not packaged in the form that has been requested it
looks to me as if the functionality for directories already exists
within the Linux kernel.

I think this would be amazingly expensive -- every constrained fd
would need to carry an entire mount namespace with it.  That namespace
might need to have shared recursive mounts under it.  And dfds created
for subdirectories would need yet another mount namespace.  And all
these mount namespaces would probably need user namespaces to go along
with them.

It would also have odd semantics.  If you have a dfd pointing to /foo,
and /foo/link is a symlink to "../bar", then looking up "link"
relative to /foo should fail; it should not try to resolve /foo/bar.

IOW I think this is impractical.

Eric