[dm-crypt] Kernel Keyring Service
arno at wagner.name
Sun Dec 14 03:41:54 CET 2014
On Sat, Dec 13, 2014 at 04:40:13 CET, Alex Elsayed wrote:
> Arno Wagner wrote:
> > On Fri, Dec 12, 2014 at 17:23:20 CET, Ahmed, Safayet (GE Global Research)
> > wrote:
> >> Is there a way to setup an encrypted partition with keys from the kernel
> >> key ring? The key-ring services support special keys called encrypted
> >> keys. These keys never exist outside kernel memory in an un-encrypted
> >> state. These encrypted keys are encrypted with other keys in the kernel
> >> keyring: user keys and trusted keys. Trusted keys are keys protected by
> >> a TPM SRK.
> >> http://lxr.free-electrons.com/source/Documentation/security/keys-trusted-encrypted.txt
> >> This would be something different from TPM-LUKS which protects keys in
> >> the
> >> TPM NVRAM. A possible advantage of using encrypted keys from the kernel
> >> key ring is that the key(s) used by dm-crypt never have to be exposed to
> >> user space in an unencrypted state. Currently, user space can see the
> >> encryption key of a dm-crypt partition in plain text by using the
> >> following command:
> >> dmsetup table --showkeys <device name>
> >> I am not entirely sure if that is an issue.
> > It is not. The Unix protection model assumes root is trusted
> > and can do anyting. Root can dump kernel memory as well. Trying
> > to put in a protection method here that is not in line with the
> > Unix protection model is not going to help much.
> Except this
> a.) hasn't been the case for a while (LSMs can restrict root, after all)
> b.) is becoming less true as time goes on (Trusted Boot support, sandboxing)
> c.) isn't actually a true assertion even if the basis were true
> Now, a more nuanced statement of "Trying to protect that data against this
> avenue of attack without also addressing the others is not much use" would
> avoid (c) - but for instance, Capsicum is emphatically not the Unix
> protection model (rather, it's object-capability), is a new protection
> method, and _works_. Even for root.
> And even so, if an API is using keys from the kernel keyring API, they are
> owned by the kernel keyring. Thus, it's the kernel keyring that gets to
> disclose them - or not, as the case may be.
> Besides - security is a _process_, not just a _state_. Closing off avenues
> of information disclosure one by one is a valid strategy. If every avenue of
> attack for any issue had to be closed off in the first patch, we'd have a
> few problems - including that every such patch would be an enormous beast
> Linus would never merge.
> >> Lastly, I just want to mention that trusted keys and encrypted keys are
> >> already used for ecryptfs:
> >> http://lxr.free-electrons.com/source/Documentation/security/keys-ecryptfs.txt
> > I would be very surprised if root could not get the ecryptfs
> > keys.
> eCryptfs doesn't provide any way to access the key via its own interface,
> and the keys are stored in the kernel keyring system - which doesn't allow
> extracting certain types of keys without them being re-
> Presuming the user is sufficiently security-conscious that they've
> restricted access to kernel memory &c (via LSMs or otherwise), no - root
> cannot get the eCryptfs key.
> Um, surprise?
I was not talking about a nice but academic model. I was talking
about reality of security: Patch the kernel on-disk, after the next
reboot all surprise is gone. Or do a cold-boot attack the same way.
In-memory kernel patching is also an option. That is a current
and used attack technique. As long as encryption is not done via
a seperate device and the kernel never sees the keys, this cannot
really be secured.
That said, it may not be a good idea in the first place to protect
anything against root-access. The root user is there for a reason.
Anything secure against root locks out the system administrator
as well. Disk-encryption on Unix cannot really be secured against
root anyways, root at the very least has full data access.
Now, if you have a separate secure device (self-encrypting disk
with its own key-pad for the passphrase for example), things are
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
More information about the dm-crypt