Timeline for Can I deny the root access to the user keys in the Kernel key retention service?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 11 at 13:55 | comment | added | Marcus Müller | @TooTea hm, I had to manually enable IOMMU in the boot kernel options to get my virtualized NIC functions to work with VMs; this might have changed. | |
| Nov 11 at 13:49 | comment | added | TooTea | @MarcusMüller Actually, Fedora runs with the "lockdown" feature enabled (man kernel_lockdown), whose goal is to stop root from arbitrarily tampering with the kernel (when under UEFI secure boot). That'll stop root from loading arbitrary modules, unless they have access to an enrolled private key to sign them. And the DMA attacks will be stopped by the IOMMU on anything halfway modern (and properly configured). | |
| Nov 10 at 18:29 | comment | added | Andrew Henle | No. Since root can overwrite kernel memory That does ignore the possibility of configuring an SE Linux-based RBAC system that could prevent root from reading kernel memory. Good luck getting such a system configured and running, nevermind maintaining it - I've actually been involved in efforts that tried... | |
| Nov 10 at 17:21 | comment | added | Stephen Kitt | Fair enough, so the onus is on the OP to clarify ;-). | |
| Nov 10 at 17:12 | comment | added | Marcus Müller | well, I secureboot a kernel (I'm too lazy to do measured boot on my laptop, but in principle I could), so that's verified at boot. I could still open /dev/mem on that Fedora machine. That's what I meant with "unless you really specify what your "etc" means": verified at boot does not imply restrained root. It just means that if all processes run as root are trustworthy (and so is the kernel and its modules), then the system is "intact". Now, OPs question seems to imply "assuming I have a misbehaving super user", and that's not covered by boot-time attestation. | |
| Nov 10 at 16:32 | comment | added | Stephen Kitt | Right, so root with the ability to replace/extend the kernel and/or physical access to the system (to control secure boot); I read “verified at boot time” as excluding that in practice. | |
| Nov 10 at 14:22 | comment | added | Marcus Müller | @StephenKitt init_module(2) with a really minimal module, or kexec_load(2) your own kernel, or, if enabled in the kernel, mknod'ing /dev/mem and writing to it, or by opening /sys/bus/pci/devices/…/resource{N} of a DMA-capable device (NIC!) and making it do DMA operations on kernel memory | |
| Nov 10 at 13:42 | comment | added | Stephen Kitt | How can root overwrite kernel memory? | |
| Nov 10 at 12:21 | history | answered | Marcus Müller | CC BY-SA 4.0 |