linux-kernel - Re: [PATCH v2] fs: block cross-uid sticky symlinks

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]

Date:	Mon, 31 May 2010 20:24:23 -0700
From:	Kees Cook <kees.cook@...onical.com>
To:	James Morris <jmorris@...ei.org>
Cc:	Christoph Hellwig <hch@...radead.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>,
	Eric Paris <eparis@...hat.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 09:09:10AM +1000, James Morris wrote:
> On Mon, 31 May 2010, Kees Cook wrote:
> 
> > Expecting the push-back from VFS, I wrote this patch against commoncaps.
> > 
> > James, would you take it there (along with the patch to SELinux to call
> > out to commoncaps) if there is no way to proceed with the VFS core towards
> > solving this?
> 
> Isn't this just bypassing the VFS objections?

Well, that's what I'm trying to understand.  It sounds like there is some
general agreement that the issue needs to be solved, but some folks do not
want it in the core VFS.  As in, the objections aren't with how symlink
behavior is changed, just that the changes would be in the fs/ directory.

My rationale is that if it's in commoncaps, it's effective for everyone, so
it might as well be in core VFS.  If the VFS objections really do boil down
to "not in fs/" then I'm curious if doing this in commoncaps is acceptable.

Ironically, doing this in commoncaps is the patch I sent.  :P

To me, the VFS objections really seem like a obfuscated version of
"this should not be in the kernel in any way", which I think does not
admit to the problem existing in the first place.  Either there is a
problem or there isn't.  If there is a problem, it should be fixed.
I think there is a problem with the kernel semantics of symlinks.
Therefore, it should be fixed in the kernel.

I personally do not care if it's in fs/ or security/, I'm just seeking
the most efficient and complete solution.

-Kees

-- 
Kees Cook
Ubuntu Security Team
--
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/