Arno Wagner wrote: > 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. The (exceedingly limited) protections of Secure Boot EFI bootloaders stop this, let alone Trusted Boot via tboot/Intel TXT. You are describing the _exact_ attack model they are designed to foil. > Or do a cold-boot attack the same way. See TRESOR, or scrubbing the key on the way down, or any number of other strategies that have already been implemented. > In-memory kernel patching is also an option. That is a current > and used attack technique. And it presumes the user has not locked down the relevant ways to do that - which is not only feasible via any number of ways using LSMs, but is an active project in order to run under Secure Boot without risking key revocation. > As long as encryption is not done via a seperate device and the kernel never sees the keys, this cannot really be secured. Technically true - the best kind of true! But not necessarily relevant: the same argument could be used to say that any security other than information- theoretic security is futile, but that is patently false in the real world - see symmetric-key ciphers, RSA, Diffie-Hellman, hashes, KDFs, and basically everything else that is actually used in cryptography. The problem has never been foolproof, 100% immunity to any potential attack. The problem has always been *changing the cost equation so that it is not worth it to the attacker* > 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. The root user is there for a reason, yes: in the original model of Unix, it represented whoever had total authority over the machine. Of course, that model was a massive, immobile shared system with restricted physical access, which may somewhat undermine its relevance to the current norm of tiny, mobile single-user systems that are left unattended or stolen with dismaying frequency. > Anything secure against root locks out the system administrator > as well. Not true. The system administrator is not root. The system administrator (ideally) should be the only one who has _access_ to root, but the system administrator is human, and thus exists outside the system. In the case of sealed/encrypted keys in the kernel keyring, the system administrator may have a second (unsealed) copy in another secured physical location. The system administrator may not, and that may be a _deliberate choice_. Presuming that root = system administrator is an *intensely* limiting assumption, because it leads to accepting security designs that cannot be used to build secure architectures larger than a single machine. Such as allowing root to read the plaintext encryption key unconditionally. > 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. My point is that "root has access to everything" is not (and honestly, has not been for a long time) inherently true in Linux, and is certainly not a design goal to *make* always true. The keyctl API alone shows that. If you aren't arguing about "should" but the futility of even trying, see my point above about how security has *never* been about perfect impenetrability. Presuming that root is (and always will be) able to access everything is an artificial, *harmful* limitiation to impose, because it *dramatically limits what can be built with Linux* - including such devices. Do you feel that use cases where the traditional Unix privilege model is insufficient are irrelevant? Despite that the existence of LSMs, sealed/encrypted keys, seccomp mode 2, Capsicum, O_BENEATH, and a vast array of other such tools is an ample existence proof that Linux tries to support such use cases? I am honestly curious, because I haven't been able to discern whether your primary objection is that restricting root is a.) futile b.) irrelevant for any use Linux will be put to or c.) ideologically wrong Hopefully, I've addressed (a) and (b) - and while (c) cannot be 'addressed' per se and we would have to agree to disagree, there is ample evidence that the kernel goes to significant effort to support such things anyway. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
