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:	Tue, 01 Jun 2010 07:55:02 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Kees Cook <kees.cook@...onical.com>,
	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, 2010-06-01 at 03:55 -0400, Christoph Hellwig wrote:
> On Mon, May 31, 2010 at 08:24:23PM -0700, Kees Cook wrote:

> > 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.
> 
> If you think the objection is about having things in fs/ you're smoking
> some really bad stuff.

Sounds to me like we should probably follow the same path as
mmap_min_addr.  We should add these hooks right in the VFS where they
belong (much like mmap_min_addr hooks into the vm) and control them 2
ways.

1) a Kconfig so distros can choose to turn it on or off by default
2) a /proc interface so root can turn it off

Nothing about that precludes additional similar checks inside an LSM
(like CONFIG_LSM_MMAP_MIN_ADDR) which can be more finely controlled.  So
maybe we want to follow up with the core VFS check with new checks in
SELinux (and maybe apparmour).  This allows the user to disable the
general check and still be provided with some modicum of protection.
You might ask why not ONLY do the check in SELinux and drop the generic
check, but we have seen with mmap_min_addr that the SELinux unconfined
user can do damn well anything it wants to, so having a non-LSM version
of appropriate security checks is highly regarded.

(see eparis.livejournal.com for a long discussion on the LSM creating a
weaker machine in some cases when there are no non-LSM checks)

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