Re: Sandbox thoughts

[Andy Lutomirski <luto amacapital net>]

On Mon, Mar 2, 2015 at 1:47 PM, Eric W. Biederman <ebiederm xmission com> wrote:
> Andy Lutomirski <luto amacapital net> writes:
>
> > On Mon, Mar 2, 2015 at 9:09 AM, Eric W. Biederman <ebiederm xmission com> wrote:
> > > MS_REC should be only required if there is something mounted on top of
> > > one of the files in sysfs.  It sounds like there is, and exposing that
> > > file would be a permission issue.
> >
> > What's mounted on /sys?
> >
> > If it's just /sys/fs stuff, then I'd argue that we should exempt it
> > and allow the non-recursive bind mount.
>
> I disagree.  Having looked at the code to remind myself excactly what we
> are dealing with the only case that will require MS_REC on a bind mount
> are locked mounts.  We have locked mounts because it was the real root
> user who mounted something on top of sysfs.
>
> All of the mounts get locked together after:
>
> unshare(CLONE_NEWUSER|CLONE_NEWNS);
>
> We don't have a reliable test that could say some mounts never need to
> be locked together.  So Andy I disagree that we should exempt anything,
> it is not technically feasible at this point.
>
> If we can figure out how to get a dentry bit that says and enforces a
> directory will always be empty and we should never lock mounts on top of
> it.  It might be worth reconsidering things.  But right now I have no
> interest in relaxing something that works and is not particularly complicated.

It's a matter of how much a problem recursive mounts are for /sys/fs.
The contents on my machine are:

$ ls /sys/fs
cgroup  ext4  fuse  pstore  selinux  xfs

We could alternatively add a *mount* bit that tells the kernel that
this mount shouldn't lock the underlying mount.

OTOH, arguably the right solution is to get userns FUSE support merged
and use it for absurd things like sysfs mounts in unprivileged
containers.

--Andy

> Eric



-- 
Andy Lutomirski
AMA Capital Management, LLC