From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Sun, 14 Dec 2014 03:41:55 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-49-177.dclient.hispeed.ch [77.57.49.177]) by v6.tansi.org (Postfix) with ESMTPA id C4F4F20DC20F for ; Sun, 14 Dec 2014 03:41:54 +0100 (CET) Date: Sun, 14 Dec 2014 03:41:54 +0100 From: Arno Wagner Message-ID: <20141214024153.GA17778@tansi.org> References: <20141213002651.GB19625@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] Kernel Keyring Service List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 > >> > >> 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@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