Message-ID: <20080912220802.GA23230@us.ibm.com>
Date:	Fri, 12 Sep 2008 17:08:02 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
	hch@...radead.org, viro@...IV.linux.org.uk,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: unprivileged mounts git tree

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> "Serge E. Hallyn" <serue@...ibm.com> writes:
> 
> > Quoting Miklos Szeredi (miklos@...redi.hu):
> >> On Thu, 11 Sep 2008, ebiederm@...ssion.com (Eric W. Biederman)
> >> > There is a weird corner case I'm trying to wrap my head around.
> >> > unlink and rmdir do not work on dentries that are mount points
> >> > in another mount namespace.
> >> > 
> >> > Which is at least needed for the moment so we don't leak mounts.
> >> > 
> >> > Once we have unprivileged mounts does that introduce a DOS attack?
> >> 
> >> Hmm, yes.  That's a tough one...
> >> 
> >> I think if the dentry has only user mounts, unlink should go ahead and
> >> on success dissolve any mounts on the dentry.  Does that sound
> >> workable?
> >> 
> >> Thanks,
> >> Miklos
> >
> > Is it really a problem?  The admin can always go ahead and kill the
> > user, which already takes care of any mounts in private namespaces,
> > which I think is Eric's primary concern.  IT also takes care of that
> > user's processes pinning files under the mounts.  So now the admin can
> > umount all the user's mounts in the init namespace (using a script
> > parsing /proc/self/mountinfo if need be), and delete the files.
> >
> > Doesn't really seem like a problem.
> >
> > Or am I missing Eric's real concern?
> 
> Assume /user is the base unprivileged mount point.
> 
> echo dummy > /tmp/1234
> mount --bind /etc /user/etc
> mount --bind /tmp/1234 /user/etc/passwd

Ok, but this is all done as root.  Kind of a silly thing for root to
do :)

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.

> 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?

> It is also contrary to classic unix and linux semantics as open files
> don't otherwise prevent unlink, rename or, rmdir from happening. So
> applications are not going to be ready for it.
> 
> At a practical level I recently replace chroot with mount namespaces
> to simplify handling of mounts and ouch!  When a process goes crazy
> and doesn't exit when you expect and then you try and delete the
> directory it is a pain.
> 
> Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists