linux-kernel - Re: [RFC][PATCH 4/3] vfs: Allow rmdir to remove mounts in all but the current mount namespace

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: <CAJfpegv+h7xh_2e-X7is9dq1Fp06A0eKwsyWFMPX=azbbDCX5Q@mail.gmail.com>
Date:	Thu, 10 Oct 2013 12:02:24 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	"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>,
	Rob Landley <rob@...dley.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC][PATCH 4/3] vfs: Allow rmdir to remove mounts in all but the
 current mount namespace

On Tue, Oct 8, 2013 at 10:50 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:

> If we are going to fix the VFS deficiency we have to let these changes
> happen in other mount namespaces.  To make that safe it has to be
> sufficient to rely on the directory permissions and the conditions that
> ensure that the directory permissions are sufficient.

Yes.

> So I find it far safer to allow as much as possible even in the local
> mount namespace so we can actually see if there are problems with
> relying on the directory permissions.

But it's not safer in terms of breaking legacy environments, which are
single namespace, usually.

I see it this way: the current behavior (blocking unlink/rename if
mounted) may not be nice, but it's expected.  But once we have
multiple namespaces it becomes problematic.   Just like  network
filesystems where we cannot prevent unlink on another host just
because it's mounted on this.  So we have to have some way of dealing
with this.

Is it worth changing behavor in the "current namespace" case too?  It
has advantages, but it's not absolutely necessary and there are
unknown dangers.  But if we disable it for rmdir() then what's the
point in enabling it for unlink()?  Directory mounts far outnumber
non-directory ones, so the additional testing is minimal, but the
holes left are probably just as real.

And there's rename().  We have a real security hole in fusermount by
allowing it in the local namespace.  I don't think changing the
behavior of rename() in the local namespace is  important enough to
risk such problems.  And as Andy pointed out, we can just have an
option to turn it on and that's that.

Thanks,
Miklos
--
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/