public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees.cook@canonical.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Young <hidave.darkstar@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>, Eric Paris <eparis@redhat.com>,
	Christoph Hellwig <hch@infradead.org>,
	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>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	David Howells <dhowells@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Tim Gardner <tim.gardner@canonical.com>,
	"Serge E. Hallyn" <serue@us.ibm.com>,
	tytso@mit.edu, Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH v6] fs: allow protected cross-uid sticky symlinks
Date: Thu, 3 Jun 2010 14:00:51 -0700	[thread overview]
Message-ID: <20100603210051.GD4714@outflux.net> (raw)
In-Reply-To: <m11vcnlw9j.fsf@fess.ebiederm.org>

On Thu, Jun 03, 2010 at 01:02:48PM -0700, Eric W. Biederman wrote:
> Kees Cook <kees.cook@canonical.com> writes:
> > A long-standing class of security issues is the symlink-based
> > time-of-check-time-of-use race, most commonly seen in world-writable
> > directories like /tmp. The common method of exploitation of this flaw
> 
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> 
> This approach to fix the problem to of /tmp looks to me like it
> will have the opposite effect.  I think this patch will encourage
> more badly written applications.

How to safely deal with /tmp has been well understood for well over
a decade.  I don't think this change would "encourage" poor code.

> This patch does not actually fix the problem of recurring security
> issues in /tmp.  Fundamentally /tmp is a design flaw. You have
> evidence that even the introduction of the sticky bit, and O_NOFOLLOW
> did not fix this design flaw, I don't see how yet another kernel feature
> will make finally make /tmp secure.  The design flaw in /tmp is that we
> encourage storing files that we care little about (temporary files) in
> a location that is shared between everyone.  From a security point of
> view sharing of files needs to be done very carefully, and as such
> should only be done for files that we really care about and intend to
> share.

I agree about /tmp being perilous.  This change, however, fixes a class of
problems that exist now and has a simple solution.

> Furthermore the set of applications with security problems you are intending
> to address are privileged applications.   There is no excuse not to audit
> and fix those applications.  If you include this patch I see no reason why
> audits won't get more lax and other related security issues won't crop up.

If there were no excuse, then all software would be audited.  This just
isn't the reality of our world.  Auditing is not a binary process and
auditing for security issues is, unfortunately, not a high priority for
many projects or organizations.  If auditing was critically important,
able to find all flaws, and there was no excuse not to do it, then Linux
would never have any security vulnerabilities.  I do not believe in
perfect security; I believe in layered security.  Find and fix what we
can when we can.  This change provides coverage for all software running
on the kernel for this flaw.

> The real solution to this problem of inadvertently sharing things that are
> not safe to be shared is not to have a shared /tmp at all.
> 
> Per user tmp can be as simple as:
> export TMPDIR=$HOME/tmp/
> chmod 0500 /tmp

Again, I agree the traditional /tmp should ultimately go away.  It is,
however, not that simple today.  I'm all for having distros go this
route and fix the various issues surrounding getting rid of the common
/tmp area.  This patch is to solve one specific problem with no trade-off.

> So is your interest in actually fixing this problem, or do you just
> want to encourage more bad applications to be written without worrying
> about inadvertent sharing in /tmp?

I obviously don't believe it is one or the other.  I want to fix /tmp
symlink races today and then see to fixing /tmp sharing next.

-Kees

-- 
Kees Cook
Ubuntu Security Team

  reply	other threads:[~2010-06-03 21:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-03  8:01 [PATCH v6] fs: allow protected cross-uid sticky symlinks Kees Cook
2010-06-03  9:41 ` Alan Cox
2010-06-03 18:40   ` Kees Cook
2010-06-04  4:39     ` Al Viro
2010-06-04  6:23       ` Kees Cook
2010-06-03 20:02 ` Eric W. Biederman
2010-06-03 21:00   ` Kees Cook [this message]
2010-06-07 16:18     ` Valdis.Kletnieks
2010-06-07 16:42       ` Kees Cook
2010-06-07 18:36         ` Eric W. Biederman
2010-06-07 21:06           ` Kees Cook
2010-06-08  8:25             ` Alan Cox
2010-06-07 19:10       ` Serge E. Hallyn

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=20100603210051.GD4714@outflux.net \
    --to=kees.cook@canonical.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@redhat.com \
    --cc=hch@infradead.org \
    --cc=hidave.darkstar@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=jmorris@namei.org \
    --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 \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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