enable Kernel Lockdown Mode / `lockdown=confidentiality` / `echo confidentiality > /sys/kernel/security/lockdown`

[adrelanos]

Reason why the kernel parameter lockdown=confidentiality got disabled in the past:

@adrelanos

Have to disable kernel lockdown. Unfortunately. Because that enforces kernel module signature verification. Which we don’t have yet.

Should we be enabling kernel lockdown during the boot process? After the kernel modules (tirdad; VirtualBox guest additions, if applicable) have been load, we could enable lockdown mode.

Thanks to @ArrayBolt3 for suggesting this!

---

How to enable lockdown mode during the boot process?

Requires root.

echo confidentiality > /sys/kernel/security/lockdown

---

How does that work?

cat /sys/kernel/security/lockdown

[none] integrity confidentiality

Kernel boots with lockdown mode none. Let's enable lockdown=confidentiality.

echo confidentiality > /sys/kernel/security/lockdown

Done. Let's see if that worked.

cat /sys/kernel/security/lockdown

confidentiality

Yes, lockdown=confidentiality has been enabled.

Once enabled, it cannot be reset, see:

echo none > /sys/kernel/security/lockdown

echo: write error: operation not permitted zsh: exit 1

---

older discussions:

• https://forums.whonix.org/t/kernel-hardening-security-misc/7296/315
• https://forums.whonix.org/t/activating-lockdown/18740

related:

• https://forums.whonix.org/t/enforce-kernel-module-software-signature-verification-module-signing-disallow-kernel-module-loading-by-default/7880

---

todo:

• APT trigger to point out that unsigned kernel modules which have been updated cannot be re-load without a reboot
  • needrestart would be great in theory but had LPE (https://forums.whonix.org/t/add-package-needrestart/19078)

[ArrayBolt3]

Because enabling lockdown mode in this way would still allow arbitrary kernel modules to be loaded before lockdown mode was enabled, this means an attacker who gains root privileges on the system will still be able to do anything they could do without lockdown mode in their way, so long as they set up a persistent compromise that activates itself before lockdown mode is enabled (this can probably be done trivially with a systemd unit).

While I did make the suggestion, I still haven't figured out a threat model this would actually protect against. The reason /proc/kcore is nonexistent when lockdown mode is active is to hide in-kernel cryptographic data from userspace. Keeping even the root user from seeing that sounds valuable, but what all would that prevent? (Note that cryptographic data in all userspace processes can still be accessed via /proc/PID/mem.)

• Raw LUKS keys won't be able to be extracted from kernel memory.
  • This sounds great in theory, but the LUKS key is really only valuable if the attacker can't get data from the disk any other way, or if the user has decided to use the same LUKS master key in multiple locations (not the same LUKS passphrase, but the same underlying LUKS key).
    • For the former situation, the only way to even get the LUKS key with kernel lockdown disabled is if an attacker gains arbitrary code execution as root. At that point getting the key is pointless; since the attacker is root, they can read any files they want from the filesystem (and if they're after deleted files or other hidden data, they can read /dev/mapper/luks-UUID).
    • For the latter situation, it is plausible the same LUKS master key may be used in multiple locations if the user clones a VM that is LUKS-protected. Our VM images are unencrypted by default, but someone might still use LUKS inside a VM if they install Kicksecure from an ISO. In this instance, an attacker might find the master key useful so they can decrypt the cloned VMs and steal their data also. But if the attacker has access to the cloned VMs, they have access to the host in some capacity. In that instance, the attacker may be able to dump the memory of the guest via the hypervisor software or the host's kernel features, which will obviously bypass lockdown mode inside the guest.
      • Under raw QEMU, an attacker can simply open the QEMU "monitor" and use the dump-guest-memory command. This requires the attacker have access to the user account under which the QEMU VMs run, or be able to connect to the socket/device/file descriptor/whatever QEMU is exposing the QEMU monitor over. (File permissions might prevent an attacker from reading a VM core dump they create even if they are able to make QEMU create the dump by connecting to a socket or similar with improperly set permissions.)
      • Under libvirt (which is what our KVM instructions use), an attacker can use virsh dump. This requires that they be able to connect to libvirt, which requires root privileges if the VMs are running under qemu:///system (the default configuration), and probably does not require root privileges if the VMs are running under qemu:///session.
      • Under VirtualBox, an attacker can use VBoxManage debugvm ... dumpvmcore. This requires the attacker have access to the user account under which the VirtualBox VMs run (I'm able to use it against a test VM here without root permissions).
      • In conclusion, an attacker with access to the VM host either as root or as the user the VMs run as will be able to dump memory and read it. Most of our KVM users will probably not be affected if the attacker is unable to get root access on the host, VirtualBox users don't get this layer of protection.
  • Personally I feel like this is a pretty niche attack scenario, many users won't be using encrypted VMs, and those that do can mitigate shared LUKS keys by doing multiple VM installations rather than cloning VMs.
• Applications that make use of the kernel crypto API in userspace may be able to load cryptographic data into the kernel to protect it from userspace memory dumps. This would then be inaccessible to an attacker.
  • This is potentially a very compelling advantage; imagine a TLS implementation that offloads all cryptographic operations to the kernel. The keys for the connection would only be in userspace long enough to load them into the kernel, then the userspace application would wipe the keys from its memory and rely on the kernel to handle the rest of the crypto. An attacker would be unable to leak TLS keys to decrypt the connection in this scenario. This is only one of many possible useful scenarios.
  • The question then is, are there applications that actually use this API? Apparently OpenSSL uses it in some spots (https://mta.openssl.org/pipermail/openssl-users/2023-January/015789.html), IPsec also probably uses it (https://blog.cloudflare.com/the-linux-crypto-api-for-user-applications/), and there are a few applications that use the libkcapi library in kcapi-tools in Debian 13. It is unclear if any of these tools wipe keys from userspace after import into the kernel.
  • Even with these advantages, an attacker that manages to get a memory dump from the process before it wiped the key from memory would still be able to steal keys. It's unclear whether the kernel crypto API allows keeping all sensitive cryptography operations purely in the kernel in such a way that an attacker would be unable to leak keys if memory is leaked from processes at the right time. The fact that we disallow ptrace would probably make this key leak harder to do and possibly even unreliable, but it would still be theoretically possible.
• Any other cryptographic data stored in the kernel?

It's also possible sensitive data managed by some in-kernel processes will be restricted from root's view, but it's somewhat hard to imagine what data this would be (maybe GPU memory or similar?). Especially when one takes into account that all it takes is a reboot for the attacker to be able to bypass all of this by loading a custom kernel module during early boot, I don't know if this is worth it. More opinions needed, IMO.