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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100607164257.GD6839@outflux.net>
Date:	Mon, 7 Jun 2010 09:42:57 -0700
From:	Kees Cook <kees.cook@...onical.com>
To:	Valdis.Kletnieks@...edu
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Dave Young <hidave.darkstar@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Eric Paris <eparis@...hat.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>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	David Howells <dhowells@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Tim Gardner <tim.gardner@...onical.com>,
	"Serge E. Hallyn" <serue@...ibm.com>, tytso@....edu,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH v6] fs: allow protected cross-uid sticky symlinks

On Mon, Jun 07, 2010 at 12:18:56PM -0400, Valdis.Kletnieks@...edu wrote:
> On Thu, 03 Jun 2010 14:00:51 PDT, Kees Cook said:
> > On Thu, Jun 03, 2010 at 01:02:48PM -0700, Eric W. Biederman wrote:
> > > Kees Cook <kees.cook@...onical.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@...ssion.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.
> 
> The fact that you're proposing this patch a decade after we "well understood"
> the problem should suggest that it *will* encourage poor code, as the same
> programmers who don't currently get it right (and are thus the targets of your
> patch) will quite likely just say "Oh, I saw a patch for that, I don't have to
> try to do it right..."

This objection and its rebuttal are entirely conjecture and I don't think
it matters since we can never know the objective truth about the education
or motivation of nameless coders.  That said, I would assume that anyone
well-educated enough about /tmp races to think "oh I saw a kernel patch
for that" was either going to get it right to begin with or was going to
ignore best practices anyway.  The issue is more about the people that
just don't think about it at all.  I would argue that people are still
doing it, for over a decade, when it's still vulnerable, is evidence
that it is not something that will improve.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ