Re: [GIT PULL] Kernel lockdown for secure boot

From: Andy Lutomirski
Date: Tue Apr 03 2018 - 18:39:51 EST

On Tue, Apr 3, 2018 at 3:32 PM, David Howells <dhowells@xxxxxxxxxx> wrote:
> Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>> > If the user can arbitrarily modify the running kernel image, you cannot
>> > trust anything. You cannot determine the trustworthiness of something
>> > because your basis for determining that trust can be compromised.
>> 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't.
> Eh? If the attacker can't what? Did you mean to put "can" at the end of that
> rather than "can't"? I don't see why the kernel-level trust would be
> compromised if an attacker can't get root and can't modify the running kernel
> image.

Whoops, yes.

> Here's a simple scenario: You boot your machine. You have module verification
> keys in your kernel. You have /dev/mem available for root to read/write. A
> program running as root can modify the keys in your kernel or just disable the
> checking code entirely. It can now insmod any module it likes. You may as
> well not bother with signed modules. In fact, it can modify the running
> kernel image in any way it likes, without even having to load modules.

I don't particularly disagree with any of this, but you seem to be
saying "if you've bought into the party line wrt signed modules, you
had better enable lockdown, too". I *don't* buy into the party line
about why signed modules should be needed for Secure Boot.

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

>> > Stopping the kernel from being arbitrarily read stops any encryption keys it
>> > may be using from being retrieved.
>> If I build a server that runs Panera Bread 2.0's website, and the
>> attacker exploits my machine to steal tens of millions of customer
>> records by getting the machine to talk to some database server using
>> keys that are securely stored in the kernel keyring, ...
> I was thinking more in terms of preventing access to the encrypted data on
> your own disk. The key for that could be unlocked using a TPM, but the
> session key then has to be retained in RAM for performance reasons unless you
> can transfer the session key to, say, your SATA controller without it going
> through the CPU.
> 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.

> But, as you suggest, they could also protect secrets used in communications.
> However, the communications themselves have to be exposed to userspace for
> userspace to be able to use them. That is unavoidable. The kernel keyring,
> for example, tries to restrict who can even see a key, much less use it as
> much as possible - but ptrace() exists... You are no less vulnerable if the
> key is held in a userspace process; then the attacker can get the key and the
> data.
> If the kernel is locked down, the aim is to try and make sure that keys
> stashed in the kernel cannot be read, though they have to be able to be used,
> or there's no point to them.

Sure. I have no problem with having an upstream kernel have a
lockdown feature, although I think that feature should distinguish
between reads and writes. 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.