Re: [dm-crypt] Kernel Keyring Service

[Arno Wagner <arno@wagner.name>]

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@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