Message-ID: <20100601173157.GE4426@thunk.org>
Date:	Tue, 1 Jun 2010 13:31:57 -0400
From:	tytso@....edu
To:	Eric Paris <eparis@...hat.com>
Cc:	Kees Cook <kees.cook@...onical.com>,
	Christoph Hellwig <hch@...radead.org>,
	James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org,
	Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Dave Young <hidave.darkstar@...il.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	David Howells <dhowells@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tim Gardner <tim.gardner@...onical.com>,
	"Serge E. Hallyn" <serue@...ibm.com>
Subject: Re: [PATCH v2] fs: block cross-uid sticky symlinks

On Tue, Jun 01, 2010 at 11:34:37AM -0400, Eric Paris wrote:
> 
> Seems like one of Alan's main arguments is that you should not turn it
> on 'by default.'  I assume most distros will want it on by default.
> Alan made the same argument against mmap_min_addr (known to break dos
> emu) but I think most major distros have it on by default these days
> even if it does break those weird obscure use cases.  I guess distros
> can do it through sysctl but Fedora, at least, likes to keep those
> default if possible, which is why I suggested the CONFIG.  In any case,
> putting this right square in the VFS where it happens makes the most
> sense to me.

If the use cases where people would really want to support following a
third-party symlink located in a world-writable sticky-bitted
directory are real (I'm not really convinced they really are real),
then it might make more sense to do it as a sysctl-controlled variable
with distro's chooinsg to enable it by default in their shipped
/etc/sysctl.conf file.  That way their users/customers will be able to
more easily disable the security feature if it really matters.

That being said, I'm not at all convinced there are any legtimiate use
cases that would be impacted by this change, and as I've pointed out
earlier, I don't think the "POSIX doesn't allow this change" argument
holds water, since POSIX originally didn't even allow for the
semantics for the sticky-bit on directories.  The real argument is
going to come from traditionalists, who will argue, "that isn't the
traditional behaviour!"

How strongly you buy this as an argument is going to be religious
argument, since it's doubtful that it people can come up with real use
cases that will actually break with that sort of change --- especially
given that the vast majority of Linux systems are single-user systems,
and the main concern will be a privilege escalation attacks.

> I'd also like to point out that I don't buy the argument that per
> user /tmp/ is a 'better' solution for the general case.  Any application
> that would be broken by this change will also be broken by per
> user /tmp.  Now, if we used filesystem namespaces regularly for years
> and users, administrators, and developers dealt with them often I agree
> that would probably be the preferred solution.  It would solve this
> issue, but in introduces a whole host of other problems that are even
> more obvious and even likely to bite people.

Per-user /tmp solves other problems as well, though --- especially for
people who care a whole lot about mandatory access control scenarios,
for example.  

I do have a slight preference against per-user /tmp mostly because it
gets confusing for administrators, and because it could be used by
rootkits to hide themselves in ways that would be hard for most system
administrators to find.

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