Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Is it possible to prevent a root user (user space) from running dmsetup table --showkeys to dump the LUKS master key?
I know of the TRESOR patch which essentially prevents the key from persisting in memory, and for all purposes makes the key unreadable from anything but RING0. Does/can the dmsetup command override this?
(Contextually: if an attacker gets root on a machine, it'd be nice to prevent/make it harder for them to dump this key in case of physical attack)
No, not that I'd know of. You could maybe remove the dmsetup binary from the system and only keep it in the initial ram disk, which would be enough to set up the encrypted volumes when the machine booted, and then chroot the initial ramdisk out of reach in the booted system, but this would only be a stopgap measure. You might be able to improve on it with apparmor profiles a bit, but not make it watertight (especially not against a simple download of the binary from the network).
That said, Luks is designed to keep data confidential only when it is at rest. If you're trying to avoid having the luks key stolen while the container is in use, that will most likely turn out to be hopeless.
To expand on that a bit: Even if the dmsetup binary could be coaxed into not outputting the key, root would still have access to /proc/, which would allow him access to system memory, to the encryption and decryption etc. The only way to keep the key fairly safe would be to prevent the kernel itself having access to the key, and that's obviously not possible with just software.
I see this question was posted in Nov 2016, but LUKS2 (released in 2018) added the ability to have keyslots stored on a distinct device than the encrypted volume's device.
If you do this, then a FDE drive can be setup so it contains no plaintext metadata and the drive's entire contents is indistinguishable from random bits.
Of course you'd still need to have your master key stored in memory as a requirement for decrypting the drive's contents, but the device with the LUKS header (including the symmetrically encrypted master key, salts, etc) could be stored on an external drive (eg a USB drive) and removed after decrypting your LUKS volume. And--as needed--the master key stored in RAM can be removed from memory (which of course prevents further access to your drive's decrypted contents) using luksSuspend
