[GIT PULL] Kernel lockdown for secure boot
Alan Cox
gnomes at lxorguk.ukuu.org.uk
Thu Apr 5 14:58:25 UTC 2018
On Wed, 04 Apr 2018 00:12:04 +0000
Matthew Garrett <mjg59 at google.com> wrote:
> On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds
> <torvalds at linux-foundation.org>
> wrote:
> > Still better than telling them to disable/enable secure boot, which
> > they may or may not even be able to to.
>
> Users who can boot a non-vendor Linux distribution on their platform can
> disable Secure Boot 100% of the time.
So can anyone else, or ignore it. Vendors of all OS's have released
enough buggy but signed kernel images over the past years that rummaging
around in the archive will find you a wide choice of signed boot images
that'll then let you do wtf you like including chaining some other target.
It was IMHO broken by design, it's always been broken by design and the
horse left the stable several years ago. Key revocation is hard, nobody
ever gets it right.
Thus "secure" boot is irrelevant to all of this
The most useful application of this kind of hardening is against remote
attacks. I don't care too much that someone local can attack my machine.
They can also steal it, ask me nicely with a baseball bat to remember the
password and so on.
If my box boots a random unsigned image that has these kinds of hardening
enabled then by the time it's on a network it's much much trickier to
attack. Yes you might be able to update the boot and reboot - but if I've
got that far I can insert an ancient buggy signed kernel image from a
vendor and chain through that anyway.
Real men boot security sensitive servers off a write protected SD card. If
your enterprise vendor doesn't supply a write protect for the boot
partition then maybe you should ask them why they don't 8)
In some ways the real application for this stuff is embedded. Whatever
the boot process most embedded devices benefit from that kind of lock
down.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive
mailing list