public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Kees Cook <kees.cook@canonical.com>,
	James Morris <jmorris@namei.org>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
	Randy Dunlap <rdunlap@xenotime.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Dave Young <hidave.darkstar@gmail.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	David Howells <dhowells@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Tim Gardner <tim.gardner@canonical.com>,
	"Serge E. Hallyn" <serue@us.ibm.com>
Subject: Re: [PATCH v2] fs: block cross-uid sticky symlinks
Date: Tue, 01 Jun 2010 07:55:02 -0400	[thread overview]
Message-ID: <1275393302.2690.13.camel@localhost> (raw)
In-Reply-To: <20100601075529.GA11397@infradead.org>

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


  reply	other threads:[~2010-06-01 11:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-31  3:04 [PATCH v2] fs: block cross-uid sticky symlinks Kees Cook
2010-05-31  3:50 ` Eric W. Biederman
2010-05-31  4:12   ` Kees Cook
2010-05-31  3:54 ` Eric Paris
2010-05-31  4:23   ` Kees Cook
2010-05-31 10:23 ` Alan Cox
2010-05-31 17:50   ` Kees Cook
2010-05-31 18:09     ` Alan Cox
2010-05-31 19:07       ` Kees Cook
2010-05-31 19:52         ` Al Viro
2010-05-31 22:00           ` Kees Cook
2010-05-31 19:27     ` Al Viro
2010-05-31 10:35 ` Christoph Hellwig
2010-05-31 17:57   ` Kees Cook
2010-05-31 23:09     ` James Morris
2010-06-01  3:24       ` Kees Cook
2010-06-01  7:55         ` Christoph Hellwig
2010-06-01 11:55           ` Eric Paris [this message]
2010-06-01 14:52             ` Kees Cook
2010-06-01 15:34               ` Eric Paris
2010-06-01 17:31                 ` tytso
2010-06-01 15:00           ` Kees Cook
2010-05-31 10:47 ` tytso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1275393302.2690.13.camel@localhost \
    --to=eparis@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hch@infradead.org \
    --cc=hidave.darkstar@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=jmorris@namei.org \
    --cc=kees.cook@canonical.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rdunlap@xenotime.net \
    --cc=schwidefsky@de.ibm.com \
    --cc=serue@us.ibm.com \
    --cc=tim.gardner@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox