linux-kernel - Re: [GIT PULL] Load keys from signed PE binaries

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Feb 2013 04:23:38 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	David Howells <dhowells@...hat.com>,
	Florian Weimer <fw@...eb.enyo.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Josh Boyer <jwboyer@...hat.com>,
	Peter Jones <pjones@...hat.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	Kees Cook <keescook@...omium.org>, keyrings@...ux-nfs.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Load keys from signed PE binaries

On Mon, Feb 25, 2013 at 08:13:24PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 04:04:56AM +0000, Matthew Garrett wrote:
> > There's no reason for the LF or generic shim to be blacklisted, since 
> > neither will load anything without manual intervention. But that also 
> > means that anyone trying to boot them has to have some knowledge of 
> > English, and that there's no way to netboot them. But sure, anyone 
> > planning that approach has much less to worry about.
> 
> I don't see anything about "manual intervention" in the wording that you
> provided from Microsoft absolving you from the "duty" you feel you owe
> them.  I understand you are worried about "automated" exploits, but that
> really is just a semantic overall, as we know it is easy to get people
> to hit a key when booting just to get on with the process.

If the user has explicitly enrolled a hash then they're stepping outside 
the trust model. That's why the LF loader shows dire warnings, and why 
shim has deliberately awkward UI. Perhaps we'll have made an incorrect 
judgement and it'll turn out that users can still be manipulated into 
being exploited this way, and in that case we'll have to reappraise some 
of those choices. But given that the barrier there is similar to the 
barrier involved in just telling users to disable Secure Boot entirely, 
I don't think it's terribly likely.

> > > Yes you can.  There are all sorts of fun ways you can do this, I can
> > > think of a few more at the moment as well.  So, where does it stop?
> > > And why stop it at all?  Why not just forbid root users at all?
> > 
> > Because there's a distinction between ring 0 and ring 3?
> 
> Since when did you start trusting ring 0 code?  Bozos like me write this
> stuff, surely it isn't secure :)

The fact that we bother with CVEs seems to suggest that we at least 
aspire to it...

> > Right. We've failed at creating an alternative. That doesn't mean that 
> > we get to skip the responsibilities associated with the choice we've 
> > made.
> 
> Wait, who is "we" here?  The community?  The community over-all didn't
> agree with anything with Microsoft, that is between the people getting a
> signed key and Microsoft.  Again, you are trying to push your (prior)
> company's agreement between them and Microsoft onto the community, and
> now the community is pushing back, is that a surprise?

The community's not obliged to take the patches, and I'm sure Red Hat 
and any other vendors who care can carry them themselves. But it'd be 
nice to avoid even more divergence between upstream and the 
distributions, wouldn't it?

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/