Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

On Sat, 2012-11-03 at 13:46 +0000, Matthew Garrett wrote:
> On Sat, Nov 03, 2012 at 12:03:56PM +0000, James Bottomley wrote:
> > On Sat, 2012-11-03 at 00:22 +0000, Matthew Garrett wrote:
> > > Why would an attacker use one of those Linux systems? There's going to 
> > > be plenty available that don't have that restriction.
> > 
> > It's called best practices.  If someone else releases something that
> > doesn't conform to them, then it's their signing key in jeopardy, not
> > yours.  You surely must see that the goal of securing "everything"
> > against "anything" isn't achievable because if someone releases a
> > bootloader not conforming to the best practices, why would they have
> > bothered to include your secure boot lockdowns in their kernel.  In
> > other words, you lost ab initio, so it's pointless to cite this type of
> > thing as a rationale for a kernel lockdown patch.
> 
> I... what? Our signed bootloader will boot our signed kernel without any 
> physically present end-user involvement. We therefore need to make it 
> as difficult as practically possible for an attacker to use our signed 
> bootloader and our signed kernel as an attack vector against other 
> operating systems, which includes worrying about hibernate and kexec. If 
> people want to support this use case then patches to deal with that need 
> to be present in the upstream kernel.

Right, but what I'm telling you is that by deciding to allow automatic
first boot, you're causing the windows attack vector problem.  You could
easily do a present user test only on first boot which would eliminate
it.  Instead, we get all of this.

By analogy, it's like an architect trying to design a house to be secure
without a front door lock.  If you just secure the front door, you don't
necessarily need all the internal security.  There is certainly a market
for houses with good internal security, but not everyone wants the
hassle, so trying to make every house that way is counterproductive.
It's also not so useful to the people who want specialist internal
security because they're willing to use much more specialised systems
than you have to deploy generally.

In short, if you'd just separate the problem into

     1. What do we have to do to prevent Linux being used to attack
        windows and thus getting our key revoked from,
     2. What specialised systems can we put in place to enhance linux
        security with secure boot for those who want it

It becomes a lot simpler than trying to do a one size fits all solution.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/