Message-ID: <CALCETrUzJjTDT6mxEoQg=cq9jOvw8mn9dLQ=q=qko+oEwkGsVQ@mail.gmail.com>
Date:	Wed, 14 Aug 2013 23:52:11 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Miklos Szeredi <miklos@...redi.hu>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: DoS with unprivileged mounts

On Wed, Aug 14, 2013 at 11:45 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> Miklos Szeredi <miklos@...redi.hu> writes:
>
>> On Wed, Aug 14, 2013 at 9:32 PM, Eric W. Biederman
>> <ebiederm@...ssion.com> wrote:
>>
>>>> The solution is also theoretically simple: mounts in unpriv namespaces
>>>> are marked "volatile" and are dissolved on an unlink type operation.
>>>>
>>>> Such volatile mounts would be useful in general too.
>>>
>>> Agreed.
>>>
>>> This is a problem that is a general pain with mount namespaces in
>>> general.
>>>
>>> I think the real technical hurdle is finding the mounts t in some random
>>> mount namespace.  Once we can do that relatively efficiently the rest
>>> becomes simple.
>>
>> We already have a "struct mountpoint" hashed on the dentry.  Chaining
>> mounts on that mountpoint would be trivial.  And we need a
>> MNT_VOLATILE flag and that's it.  If we fear that traversing the list
>> of mounts on the dentry to check for non-volatile ones then we could
>> also add a separate volatile counter to struct mountpoint and a
>> matching flag to the dentry.  But I don't think that's really
>> necessary.
>
> *Blink* I had overlooked "struct mountpoint".  That indeed makes things
> easier.
>
> I agree we can chain "struct mount" on "struct mountpoint" and then we
> would have an efficient implementation, that does not impact the vfs
> fast path.
>
> After that it becomes a question of permissions and semantics.
>
> I am in the process of adopting the rule that something that is not
> visible at the time we copy a set of mounts should not become visible
> in the child mount namespace.  Grr.  This has been a busy month and
> despite having been reviewed I haven't gotten around to pushing that
> patch to linux-next.
>
> But MNT_VOLATILE by definition can not reveal anything becasue the
> underlying mount point is removed, so that all of that weirdness is in
> propogating mounts between mount namespaces is not relevant here.
>
> This is however the propogation of an unmount between mount namespaces.
>
> In general we don't even need the MNT_VOLATILE flag we just need the
> appropriate permission checks.  However we do need something like
> MNT_VOLATILE to prevent surprises.  MNT_VOLATILE would be used to
> prevent things like:
>
> # mount --bind /  /mnt
> # rmdir /mnt/usr
>
> I think the root user would be rather annoyed if that worked, so it does
> appear we need something like MNT_VOLATILE.
>
> Part of me does prefer the semantics Andy has suggested where instead of
> unmounting things we have something like a skeleton of the mount tree
> unioned with dcaches of the filesystems themselves.  With "struct
> mountpoint" we are amazing close to that already.

Two possible nasty cases:

1. mount whatever /tmp/foo/bar; rmdir /tmp/foo/bar; rmdir /tmp/foo

Presumably ls /tmp shouldn't show foo.  Should cd /tmp/foo/bar work?
What about umount /tmp/foo/bar?  What about cd /tmp/foo?

2. mount whatever /tmp/foo; rmdir /tmp/foo; mkdir /tmp/foo

Ugh.

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