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

[Andy Lutomirski]

On Jul 29, 2014 11:25 PM, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> wrote:
>
>
> I have cut this down to just focus on O_BENEATH openat case.
>
> David Drysdale <drysdale@xxxxxxxxxx> writes:
>
> > On Mon, Jul 28, 2014 at 10:13 PM, Eric W. Biederman
> > <ebiederm@xxxxxxxxxxxx> wrote:
>
> >> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/