Message-ID: <10232.1522797179@warthog.procyon.org.uk>
Date:   Wed, 04 Apr 2018 00:12:59 +0100
From:   David Howells <dhowells@...hat.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     dhowells@...hat.com, Matthew Garrett <mjg59@...gle.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        James Morris <jmorris@...ei.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Justin Forbes <jforbes@...hat.com>,
        linux-man <linux-man@...r.kernel.org>, joeyli <jlee@...e.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski <luto@...nel.org> wrote:

> I'm having a very, very hard time coming up with a scenario where I
> can "trust" something if an attacker can get root but can't modify the
> running kernel image but I can't "trust" something if the attacker
> can [modify the running kernel image].

(I think the above is what you meant)

Let's go at this a different way.  How do you decide you can trust something
in this context?  You compare it to something.  Signing it, keeping a hash
whitelist, IMA - these are all ways of comparing something.  Do you agree with
that?

However, the comparison can be subverted if the running kernel image (I might
be better saying running kernel state here since I'm not talking about the
source bzImage file) can be modified arbitrarily by userspace, either by
modifying the data against which the comparison is made - e.g. the public key
set or the hash list - or by modifying the code that makes the comparison.

/dev/mem, direct access to DMA, bpf, etc. all provide ways of modifying the
kernel image arbitrarily, which leads me to this:

> I *don't* buy into the party line about why signed modules should be needed
> for Secure Boot.

Modules are just another way of modifying the kernel image.  If I can just
create an arbitrary module and load it, then I can modify the kernel image
from within the module.

Locking down modules by signing, hashing or IMA practically prevents the
loading of arbitrarily constructed modules and only permits modules from a set
that the provider of the modules somewhat trusts.

What use is secure boot if processes run as root can subvert your kernel?

> > There's no point bothering with UID/GID checking either.
> 
> Give me a break.  There's a *huge* difference between a system where
> only root can load unsigned modules and a system where anyone can load
> unsigned modules.

I don't think we've ever advocated letting just anyone load a module.

But my point is that if you can modify the running kernel, you can nullify all
security checks, including UID/GID checks.

> > However, if /dev/mem can be read, any root process can extract the session
> > key for your disk.
> 
> Any root process can read /dev/mapper/plaintext_disk, lockdown or otherwise.

True - for now - and they can also access the mounted filesystem.  But if they
get their hands on your powered-off computer, no, they can't.

> But I don't think the upstream kernel should apply a patch that ties any of
> this to Secure Boot without a genuine technical reason why it makes sense.

Because unless you turn lockdown on during kernel boot, there exists a window
of opportunity where the kernel isn't locked down and can be accessed, thereby
obviating the fact that you started in Secure Boot mode.

David

Powered by blists - more mailing lists