From: ebiederm@xmission.com (Eric W. Biederman)
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: "Serge E. Hallyn" <serge@hallyn.com>, Al Viro <viro@zeniv.linux.org.uk>,
        Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
        Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <CAJfpegsxgnSRUW-E5HM3uT5QfGyUtn_v=i4Ppkkkutp34287AA@mail.gmail.com>
Date: Wed, 14 Aug 2013 12:32:44 -0700
In-Reply-To: <CAJfpegsxgnSRUW-E5HM3uT5QfGyUtn_v=i4Ppkkkutp34287AA@mail.gmail.com>
	(Miklos Szeredi's message of "Wed, 14 Aug 2013 19:42:19 +0200")
Message-ID: <87a9kkax0j.fsf@xmission.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: DoS with unprivileged mounts
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1174
Lines: 32

Miklos Szeredi <miklos@szeredi.hu> writes:

> There's a simple and effective way to prevent unlink(2) and rename(2)
> from operating on any file or directory by simply mounting something
> on it.  In any mount instance in any namespace.
>
> Was this considered in the unprivileged mount design?

The focus was on not fooling privileged applications and some of the
secondary effects that really should have been thought about in more
depth were like this one were overlooked.

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

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/