linux-kernel - Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1534521736.3994.13.camel@HansenPartnership.com>
Date:   Fri, 17 Aug 2018 09:02:16 -0700
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Justin Forbes <jforbes@...hat.com>
Cc:     David Howells <dhowells@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Vivek Goyal <vgoyal@...hat.com>, yannik@...britzki.me,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Peter Anvin <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dave Young <dyoung@...hat.com>, Baoquan He <bhe@...hat.com>,
        Peter Jones <pjones@...hat.com>,
        Matthew Garrett <mjg59@...gle.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom
 platform keys to boot

On Fri, 2018-08-17 at 10:42 -0500, Justin Forbes wrote:
> On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> > On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
[...]
> > > We also don't necessarily want to encourage ordinary users to
> > > fiddle with the system key databases unless they really know what
> > > they are doing.  There've been cases where doing this has bricked
> > > a machine because the BIOS is buggy. Now I will grant, since
> > > you'll probably raise it if I don't;-), that this might be a good
> > > reason *for* having our own third party signing key as we could
> > > then build the key into our kernels.
> > > 
> > > But if they use a yubikey, they have to get the public key from
> > > there into the system key list or possibly the yubikey has to be
> > > accessed by the bootloader. The same for the TPM.
> > 
> > For security reasons, a Yubikey should only be connected when you
> > need it to sign something.  The TPM you can assume is always
> > available.
> > 
> 
> This is absolutely correct, the important word here being *should*.
> The reality is, with weekly kernel updates and various uses of the
> Yubikey, the average user is just going to leave it connected. We can
> lay out best practices all we want, but it seems pretty obvious that
> most users go with convenient or default.  I really wish we could
> change that, but it is unlikely.  As a result, we have to make the
> convenient or default path also fairly secure.

Imagining the worst scenario with the most stupid user doesn't prove
anything.  We have sensible users who want to achieve security.  Our
job is to design processes that help them with that goal.  Just because
someone could do something stupid is no excuse for not helping the
sensible users.  I admit this "design usable processes to help sensible
users with security" is hard (it's the reason why we've never been able
to deploy the TPM successfully for the majority of users) but they're
not impossible.

Why don't I tell you how it currently works here so you can see how
easily it would slot into a cloud deployment process?  We're designing
CI/CD images for physical systems (i.e. images that are immutable, like
those of containers).  The signing occurs in a special secure area
using a code signing service (so we don't even use a local key dongle)
after the image has been tested in the DevOps cycle.  Today, because
the image is immutable, the initrd it built to support all the cloud
physical systems and thus it can actually be linked in to the bzImage
and the entire thing signed, which solves the initrd security problem
neatly for us.  Linking a key into the bzImage as well is a trivial
addition for us, as you can see.  For us, by the way, you can also see
that providing a key in the initrd would work fine as well.

Since our images are immutable, we don't allow automatic updates.  Even
for mutable images they're a huge security and downtime risk in a cloud
environment because you just don't know what impact they'll have
without testing them.  So even before we moved to immutable images, the
process has always been to disable updates, test out the distro
proposed update first and then deploy if all tests pass.

I'm fairly certain all cloud providers have similar processes.

If we can run this process at industrial scale, there's no reason a
simpler version can't be designed for a user to follow.

James