Re: unprivileged mounts git tree

Serge E. Hallyn
2008-09-14T01:57:43Z

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
>
> > Ok, but this is all done as root. Kind of a silly thing for root to
> > do :)
>
> There are less silly examples like setting up a chroot type
> environment contained in a mount namespace and having a kernel oops
> and then not being able to delete all of your files.

I wasn't saying that I believe I can win an argument by knocking down
one example :)

In fact I'm not trying to win an argument. Because I'm quite sure you
and Miklos are right, and I just need to figure out what I'm missing.

> > So in order for me as an unprivileged user to pin a dentry by mounting
> > over it, I have to have write permission to the dentry to begin with
> > as well as the dentry being under a user=hallyn mount.
>
> That second condition is interesting requiring write permission of the
> dentry. I thought we had obviated the need for that when we added
> ownership to the mounts themselves. In this case at least it shouldn't
> it be write permission on the directory containing the dentry.

Oh no, it seems I'm wrong, that's not a condition. Just tested it.

> >> Now you can't create /etc/passwd.new and rename it to /etc/passwd.
> >> Stopping adduser from working.
> >>
> >> As Miklos said this can apply to any file or any directory, so it can
> >> be a DOS against any other user on the system.
> >
> > Except I need to own the mount as well as the dentry. So after
> > root does
> >
> > mmount --bind -o user=hallyn /home/hallyn /home/hallyn
> > mmount --bind -o user=hallyn /home/serge /home/serge
> >
> > if user serge (uid 501) tries to
> >
> > mmount --bind /etc /home/hallyn/etc
> > mmount --bind /etc /home/serge/etc
> >
> > permission for the first will be denied because serge does not
> > have write perms to /home/hallyn/etc, and permission for the second
> > will be denied because only hallyn may mount under /home/serge.
> >
> > If root properly did
> >
> > mmount --bind -o user=hallyn /home/hallyn /home/hallyn
> > mmount --bind -o user=serge /home/serge /home/serge
> >
> > and then hallyn does
> >
> > mmount --bind /etc /home/hallyn/etc
> >
> > and serge does
> >
> > mmount --bind /home/hallyn/etc /home/serge/etc
> >
> > then hallyn can still ummount /home/hallyn/etc.
> >
> > And we've decided that users cannot (for now) do shared mounts.
> > So I'm still not sure where there is the potential for danger?
>
> Ok. Let's pick on something a little more interesting.
>
> root does:
> mmount --bind -o user=hallyn /home/hallyn /home/hallyn
> hallyn does:
> mount --bind /tmp /home/hallyn/tmp
> touch dummy
> mount --bind dummy /home/hallyn/tmp/some_shared_file_I_have_write_access_to.
>
> Which allows me to transform write permissions into the ability to
> deny someone else the ability to delete a file.

Yup, that's an interesting example.

Still an admin *can* work around that, if he can sufficiently parse
/proc/self/mountinfo to know to umount
/home/hallyn/tmp/some_shared_file_I_have_write_access_to.

Is that sufficient? Probably not?

> This seems to mess up things like revoke.

Hey, do we have revoke now? :)

> At a practical level it is a real annoyance, regardless of the security
> implications.
>
> As a point of comparison plan9 does not have that restriction.

Why doesn't it have that restriction? Does it always allow you to rm a
mounted-over file?

-serge