Message-ID: <20100804025539.GD4138@outflux.net>
Date:	Tue, 3 Aug 2010 19:55:39 -0700
From:	Kees Cook <kees.cook@...onical.com>
To:	Valdis.Kletnieks@...edu
Cc:	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, Al Viro <viro@....linux.org.uk>
Subject: Re: Preview of changes to the Security susbystem for 2.6.36

On Tue, Aug 03, 2010 at 10:07:55PM -0400, Valdis.Kletnieks@...edu wrote:
> On Tue, 03 Aug 2010 15:34:51 PDT, Kees Cook said:
> > On Tue, Aug 03, 2010 at 05:38:20PM -0400, Valdis.Kletnieks@...edu wrote:
> > > The fact that a patch for one case has been used for years doesn't mean
> > > that it's a well thought out fix for the general case.
> > 
> > Well, we clearly disagree on this point. :)
> 
> Actually, we do, because you yourself have stated that:
> 
> a) It's a patch for one case.
> b) It's been around for 15 years.
> c) It doesn't even try to address the general case.
> 
> So Yama is a special case that after years still doesn't cover the genera case
> :)

Well, Yama is just an LSM. The symlink/hardlink thing has been around
forever and does sufficiently solve the general symlink race flaw. But,
whatever, we disagree about this.

> > This is the basis of our disagreement. Fixing it does do people a favor. At
> > the very least, it does me a favor because now I don't have to publish
> > security updates for an entire class of vulnerability.
> 
> Umm.. Tell you what.  I'll give you a chance to pretend you didn't
> send that from a vendor e-mail address... :)
> 
> Do you *really* want to go on record as saying "We didn't ship a fix for
> Frobozz 3.2 because The Kernel Would Stop The Obvious Exploit", when it's
> usually quite possible that somebody can come up with a different exploit
> scenario?  That's also going to go over *really* well with customers who end up
> turning off Yama because it breaks some third-party app that's doing some
> batshit crazy thing it shouldn't be doing in the first place.

Well, it drastically reduces the urgency of such a vulnerability. Besides,
if this makes a million systems safer and 1 less safe, that's still a
net win.

> > I think this is irrelevant; the symlink/hardlink combo fixes a
> > vulnerability with DAC. It's a break in the DAC security model.
> 
> Actually, if you trace it through, in almost every single case of an exploit
> abusing a symlink, at no time does the DAC model actually get violated. Every
> single access *is* in fact done according to the DAC in effect. The problem is
> that some of the accesses are not the ones the programmer intended the software
> to make.

I'm not convinced. I see what you're trying to say, but I just don't agree.
The symlink/hardlink thing is a tiny corner case of the operational
conditions under which DAC operates, and this is fixing a mistake in the
design that leads programmers into a (well known but seemingly unavoidable)
trap.

> that implement its decisions".  (Here is where you insert the clip from Indiana
> Jones and the Last Crusade: "He chose... poorly").

Yeah, my next trick will be helping people confine their web applications.
Hahaha ugh. That's an area of endless poor choices.

> > While waiting for smarter people than me make it impossible to exploit
> > security vulnerabilities in the future, I want to make it harder for
> > attackers to exploit security vulnerabilities now.
> 
> The sad part is that there are already known ways developed by smarter people.
> You just refuse to consider them as solutions and keep trying to deploy stuff
> that a sufficiently clever kid sister can bypass.

We'll agree to disagree. And at the same time I'll point out that if
SELinux is off (or app is running without policy), symlink races are just
as bad.

> > Heh, well, I have a PTRACE model. :) "Only CAP_SYSADMIN can PTRACE_ATTACH."
> 
> That's not actually a full model. ;)

alt.ptrace.die.die.die

> > Unfortunately, I'm stuck with these damned crash handlers which are really
> > just hacks to avoid writing a core to disk. Oddly, this is a solved problem
> > (via core dump patterns and distro-wide crash handlers) , but some
> > applications want to opt out of it instead of providing proper system hooks
> > to do crash analysis. Of course, with PTRACE still allowed, there's no
> > carrot (or stick) to encourage application writers to use distro-provided
> > crash handlers.
> 
> So do the obvious - ship with SELinux configured to not allow the arbitrary ptrace,
> document it, and tell them "it doesn't work, use the proper system interface instead".
> 
> :)

Perhaps later. For the moment, I'm happy with my racey anti-PTRACE
solution.

-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