linux-kernel - Re: DoS with unprivileged mounts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87bo4zfkwi.fsf@tw-ebiederman.twitter.com>
Date:	Thu, 15 Aug 2013 00:55:25 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andy Lutomirski <luto@...capital.net>
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

Andy Lutomirski <luto@...capital.net> writes:

> On Wed, Aug 14, 2013 at 11:45 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> Miklos Szeredi <miklos@...redi.hu> writes:
>>
>> 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?

You have to have two mount namespaces or at least two different paths to
to the same filesystem to make this work.  rdir /tmp/foo/bar where
/tmp/foo/bar is a mountpoint in your mount namespace will not work
because you are trying to remove a root directory.

So the semantics I would expect to see if it was implementable is
/tmp/foo and /tmp/foo/bar would continue to exist on the paths where
/tmp/foo/bar was a mount point and would disappear as soon as it was
unmounted.

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

Likewise.  I would expect to see the new /tmp/foo slide under the old
/tmp/foo mountpoint.

Essentially my expectation would be that the mount points would float
over the filesystems.  Semantically I like it, and have played with the
idea before.  Implementation wise shrug I didn't realize any of this was
close to being practically implementatable until today.

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/