CONFIG_MODULE_SIG and the unreproducible Linux Kernel

[kpcyrd]

On 9/16/24 11:23 PM, James Addison via rb-general wrote:> As a 
hypothetical attacker who might be interested in compromising
> private keys used/generated by build systems, perhaps this feature
> could thwart some of my plans.  But my next observation/thought would
> be that instead of requiring a copy of a private key to forge loadable
> kernel modules (a capability that I would presumably rarely use),
> instead I could modify the integrity checksum(s) within relevant
> kernel binaries to match my forged module(s) -- and arguably this
> would be less traceable (that is, there would be no individual key
> that could be reported as compromised upon discovery of a tampered
> kernel / kernel module).
> 
> To phrase that another way: if the attacker has write access to both
> the kernel binary (compressed or otherwise) and kernel modules on a
> particular system, and if that systems relies solely on integrity
> checksums from those files, then I believe it would be vulnerable to
> compromise, and that that compromise would be difficult to attribute.

I think at that point you could also swap the embedded public key with 
something else, or replace the executable machine code entirely. :)

 From what I understand, secure boot is meant to ensure integrity of the 
kernel image and then transfers responsibility to the kernel to only 
load authentic kernel modules. This means the hashset is part of the 
authenticated kernel image binary and acts as a merkel tree root.

The kernel modules are "special" in the way that they often reside on 
the unencrypted part of a full-disk encrypted system (somebody please 
correct me if I'm wrong or missing anything).

> The limitation is that there would be a tight coupling between a
> kernel release (git sha / tarball) and the in-tree kernel modules that
> could be loaded for it when using pure-integrity based lockdown
> limits.  That seems, to a certain extent, to be by-design of the
> feature -- but it could affect the way that some distributions
> prepare, package and apply upgrades for their users' systems.

This is intentional, "computer does as the source code says" is the 
explicit objective. I'd rather have finite sets that I can reason 
about[1] instead of open-ended public key cryptography.

[1]: assuming the security guarantees of sha256 hold

> Note also that there is some kind of vague concern about software
> freedom ringing in my mind as I write this too: the Linux kernel has
> an ABI/API, and is open source, and as a result of those, people can
> write code (even kernel modules) that are suitable for any given
> version of it.  I can appreciate that the kernel module integrity
> feature would be an opt-in, configurable mechanism that would be
> selectively enabled by individual distributions, but I also think that
> it is important to ensure that it could not become a complete lock-out
> mechanism for any particular hardware/software combination.

This is more a question of "does my UEFI allow me to boot arbitrary 
x86_64, or allow me to mint my own secure boot authority" and is 
unrelated to Linux specifics.

I appreciate your input though. :)

cheers,
kpcyrd