From: ebiederm@xmission.com (Eric W. Biederman)
To: Kees Cook <kees.cook@canonical.com>
Cc: Valdis.Kletnieks@vt.edu, 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: Mon, 07 Jun 2010 11:36:29 -0700 [thread overview]
Message-ID: <m1631ug05u.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20100607164257.GD6839@outflux.net> (Kees Cook's message of "Mon\, 7 Jun 2010 09\:42\:57 -0700")
Kees Cook <kees.cook@canonical.com> writes:
> On Mon, Jun 07, 2010 at 12:18:56PM -0400, Valdis.Kletnieks@vt.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@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.
>>
>> 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.
But we can know about distributions.
I see a patch put forward with the argument that it solves all the
problems of /tmp. The patch does not actually solve all of the
problems of /tmp but more refined claims have not been made.
With the existence of that patch I see no interest in actually solving
the slightly more challenging problem at the distribution level of
unnecessary sharing in /tmp because a handful of uses of /tmp will
have to be fixed.
> 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.
Furthermore making it impossible to exploit the races with symlinks
(the best your patch can do). Is not going to make the races impossible
to exploit by placing a different file in place of the one to be
created, or using hard links instead of symlinks.
So I would be surprised if after just your patch a system is actually
more secure from attack, once the attackers notice the change.
Eric
next prev parent reply other threads:[~2010-06-07 18:36 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
2010-06-07 16:18 ` Valdis.Kletnieks
2010-06-07 16:42 ` Kees Cook
2010-06-07 18:36 ` Eric W. Biederman [this message]
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=m1631ug05u.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dhowells@redhat.com \
--cc=eparis@redhat.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 \
--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