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- wrapped/sealed/encased-in-carbonite. 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? _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
