Andy Lutomirski <luto@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
