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- > 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? 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 different. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
