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]

Message-ID: <20130226040456.GA30717@srcf.ucam.org>
Date:	Tue, 26 Feb 2013 04:04:56 +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 07:54:16PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 03:38:04AM +0000, Matthew Garrett wrote:
> > On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > > So, once that proof is written, suddenly all of the working Linux
> > > distros's keys will be revoked?  That will be fun to watch happen, and
> > > odds are, it will not.  Imagine the PR fun that will cause :)
> > 
> > No. Why would they be?
> 
> Because they are using the "public" shim that you provided them, or the
> Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
> will end up getting their own shim signed, the rest will just use the
> one you so helpfully provided them :)

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 buy it.  Yes, I understand this is your position, and has been
> > > all along, and _maybe_ you can extend it to "we should sign our kernel
> > > modules", but to take it farther than that, like the list David has
> > > described, is not required by anyone here.
> > 
> > Failing to take it to that extent is dangerously naive. If you can do it 
> > with kernel modules, you can do it with kexec. If you can do it with 
> > kexec, you can do it with arbitrary mmio access to PCI devices.
> 
> 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?

> > Microsoft aren't dictating anything here. We're free not to use their 
> > signatures. However, if we do use their signatures, we agree to play by 
> > their rules. Nobody seems to have come up with a viable alternative, so 
> > here we are.
> 
> Ok, I keep hearing people say, "why doesn't someone else create a
> signing authority!" all the time.  And it comes down to one big thing,
> money.

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.

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