Seriously? I am not even going to disect that, but I hope if you re-read your statements in a while you notice that they are not even consistent. What I can see is that you want this very much and you do not care to what level you violate technology and observable reality. I have had this discussion numrous times and it leads nowhere. The people that think you can get the type of security you describe within the kernel and without massive and unacceptable drawbacks are living in a reality exclusion bubble. Just one thing: Nobody in their right mind would want secure boot on a Linux (or Unix) machine. Just look up all the online discussion on this, it is pretty clear that there will not be any benefits for the machine owner, but massive drawbacks, with DRM one of them. Also take into account that any serious security researcher and practitioner assumes that an attacker with physical access to the running system has won. That also means that all these magic "secure boot" or DRM technologies cannot hold water. And one more thing: If you want to protect the passphrase against root, the most simple way to use a separate system is to virtualize your system and to do encryption in the base-system. That way root in the virtualized system never gets to see any keys, does not do the crypto, cannot patch the kernel doing the crypto and cannot reboot the system doing the crypto. That way actually works, respects KISS (at least on architecture level, virtualization is pretty complex and a KISS violation in itself...) and you "only" need to prevent break-out from the virtual environment. While this is hard and currently not achived, it is also generic, not dependent on the system running inside and only weakly dependent on the one running outside and may eventually be achieved. Qemu (non-kvm), for example, may already be there. Gr"usse, Arno On Sun, Dec 14, 2014 at 10:03:03 CET, Alex Elsayed wrote: > 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 -- 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
