[dm-crypt] Kernel Keyring Service

[dm-crypt] Kernel Keyring Service

[Ahmed, Safayet (GE Global Research)]

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.

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

Thanks,

Safayet

Re: [dm-crypt] Kernel Keyring Service

[Arno Wagner]

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

Gr"usse,
Arno


> Thanks,
> 
> Safayet
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

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

Re: [dm-crypt] Kernel Keyring Service

[Alex Elsayed]

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?

Re: [dm-crypt] Kernel Keyring Service

[Arno Wagner]

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

Re: [dm-crypt] Kernel Keyring Service

[Alex Elsayed]

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.

Re: [dm-crypt] Kernel Keyring Service

[Arno Wagner]

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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

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

Re: [dm-crypt] Kernel Keyring Service

[Alasdair G Kergon]

On Fri, Dec 12, 2014 at 04:23:20PM +0000, Ahmed, Safayet (GE Global Research) wrote:
> Is there a way to setup an encrypted partition with keys from the kernel key ring? 

Having an option for device-mapper to access keys by reference instead of
directly has been discussed as a desirable future feature for a long time, but
as far as I know, nobody's got as far as starting any design discussions yet.

Alasdair

Re: [dm-crypt] Kernel Keyring Service

[Ahmed, Safayet (GE Global Research)]

I am wondering if it could be possible to create a virtual crypto module that is a wrapper for both the key-ring services and other crypto modules. The key would include two components: 1) the id of a key currently resident in the key ring, and 2) the name of the actual crypto module that you want to sit behind the wrapper. Such an approach should allow any kernel component that can use kernel crypto modules to use a key in the kernel keying with any crypto module. 

Is that too simplistic or too kludgy?

Safayet

-----Original Message-----
From: Alasdair G Kergon [mailto:agk@redhat.com] 
Sent: Friday, December 12, 2014 8:47 PM
To: Ahmed, Safayet (GE Global Research)
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Kernel Keyring Service

On Fri, Dec 12, 2014 at 04:23:20PM +0000, Ahmed, Safayet (GE Global Research) wrote:
> Is there a way to setup an encrypted partition with keys from the kernel key ring? 

Having an option for device-mapper to access keys by reference instead of directly has been discussed as a desirable future feature for a long time, but as far as I know, nobody's got as far as starting any design discussions yet.

Alasdair

Re: [dm-crypt] Kernel Keyring Service

[Milan Broz]

Hi,

On 12/12/2014 05:23 PM, 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.

...

As Alasdair said, this was discussed long time ago but never realized.

(Please do not forget that main FDE threat model is covering
offline system only and there are a lot of other attack vectors.
If we allow attacker tampering with hw or access the system on
administrator level nothing will help here.) 

But what storing key in keyring solves now? There are still issues

1) Key is still "open" in kernel memory just elsewhere

In current system the key resides in memory directly, not only in
dmcrypt but also in all crypto API providers (it must be there
if the encryption is done by CPU).

Removing key from dmcrypt structure is possible but with
crypto provider it is not so easy.

So to make it at least some sense you have to use some crypto provider
system which does not store key in memory.

No such generic provider is in upstream kernel.

(We are talking about designs like TreVisor/TRESOR, Loop amnesia and similar.
These will be never usable for generic configurations and architectures.)

2) Key must be transferred anyway

Currently the key is sent into dmcrypt in plain form in ioctl and only
root can do this. This path was audited and properly wipes all buffers
once the key is not needed.
(And yes, this is not coolest design but it is simple.)

Replacing it with transfer from kernel keyring will just move this inside
kernel but removes the KISS principle here.

(On the other side, if we have one day non-root private device-mapper devices,
keyring could help to properly isolate keys among users of these private
dmcrypt devices.)

3) We do not have proper userspace support

If you see how the LUKS is designed, it processes volume key in userspace
decrypted from keyslot. So it means redesigning keyslot operations.
(At least it means to add another level of key-hierarchy which covers
keyring operations with "encrypted keys".)

I would like to see that instead of keyslots we have configurable key
references (IOW it stores some unique ID of key stored in some token,
keyring or whatever instead of directly encrypted volume key).
But we do not have such system yet.

I know that kernel part is kind of independent to this but without
thinking how to integrate it to LUKS it does not make much sense.


So, I think using keyring is doable but I do not see it
as a thing which primarily improves security.

I see it as logic separation of functions instead (keyring handles keys,
dmcrypt block encryption). And as such it should be implemented one day.

Thanks,
Milan

Re: [dm-crypt] Kernel Keyring Service

[Ahmed, Safayet (GE Global Research)]

I apologize for the delay in my reply. Thanks to everyone for the really 
informative and insightful discussion. Also, I apologize for the length of this
 e-mail, but I tried to address all the concerns that were raised.

    1 Intended Application
    2 Intended Stack
    3 One Possible Attack Scenario
    4 What I'm Interested In
    5 Should Root Be Allowed to Access Everything Including Kernel Memory?
    6 Can Root Be Prevented From Having Complete Memory Access?
    7 Levels of Protection
    8 Concerns About DRM

1 Intended Application
----------------------

My target application is an embedded system that runs without direct or 
significant user intervention like washing machines, locomotives, and power 
generators. It is possible that with time, the target platform will require 
updates to various software components. However, the administrator that has the
 ability to make persistent changes to the system is remote and not local.
 
2 Intended Stack
-----------------

For the intended application, I am considering a stack that is similar to what 
Alex mentioned. The idea is to establish a chain of trust that is rooted in 
hardware. With Intel TXT, the BIOS ACM measures the BIOS, the BIOS measures the
 BIOS configuration and boot loader. Eventually, the kernel and initramfs are 
measured. By "measured", I mean that a hash of the component is computed and 
extended into a Platform Configuration Register (PCR) in the TPM.

Similarly, Secure Boot is configured to ensure that only a trusted GRUB image 
can run, and in turn, GRUB security mechanisms are enabled to ensure that only 
signed components (kernel and initramfs image) can be loaded into memory for 
boot.

Once a trusted kernel image is up and running with the trusted kernel arguments
 and a trusted initramfs image, the kernel is responsible for protecting user 
land (I'm talking about the mechanisms similar to what is described in 
"Documentation/security/" in the kernel source. LSMs and all).
 
Stepping back, provided that the system comes up in this trusted environment, 
it should have access to the disk. If trust is not established, there should be
 no access. The trustworthiness of the environment is established through the 
PCR values mentioned earlier. So the disk-encryption key should be locked to 
PCR values in the TPM.
 
3 One Possible Attack Scenario
------------------------------

The disk-encryption key being present in kernel space is necessary and 
acceptable. I am more concerned about the key being exposed in plain text to 
user space. I disagree with the idea that the root user should have access to 
kernel memory. I address this in greater detail further below.

To understand my concerns, consider the following scenario:

    Once the system boots under a trusted configuration, if an adversary is 
    able to get root-level access from user space, this adversary can get the 
    volume key. Then, the adversary can access the disk off line from an 
    untrusted configuration. The adversary already has the volume key and 
    does not need the correct values in the PCR to access the disk. Then, the 
    disk can be accessed from any compromised configuration.
    
4 What I'm Interested In
------------------------

I am primarily interested in disk encryption through dm-crypt alone. LUKS is 
for managing the volume key with multiple user pass phrases. LUKS does not 
offer much in the use case I described above since the system is expected to 
boot without interacting with a user.

As Milan mentioned, the kernel part is independent and I don't really see why 
dm-crypt has to be tightly tied to LUKS. Instead, I would like to be able to 
pass the volume key directly to dm-crypt in kernel space and ensure that 
that key is never exposed.

As I had mentioned in a previous email, the kernel key-ring services are 
already used to import and manage keys for IMA, EVM, and ecryptfs. These 
kernel services are directly accessed through a number of system calls. 
Also you have "keyutils" to access these services from a shell. It makes sense 
to me for all keys including the dm-crypt keys to be managed through this 
single interface rather than maintaining a separate interface for dm-crypt 
keys.

5 Should Root Be Allowed to Access Everything Including Kernel Memory?
----------------------------------------------------------------------

I don't believe so. The separation between root user and non-root user is only 
a single defense mechanism. The idea that "if root is compromised, the platform
 is completely compromised" is not acceptable.
 
From what I understand, you always see examples of arc-injection/code-injection
 attacks that allow an adversary to compromise and take over an application. 
Then, an adversary is free to pursue additional avenues for escalation of 
privilege. Even with privileged access, this access should be within the 
confines of a controlled, trusted environment.

There are already a number of mechanisms that allow the Linux kernel to be 
booted in a way that limits what root can do.  You can limit what binaries can 
be executed (even by root) with IMA appraisal. Alex already mentioned 
"capabilities" (Capcium security model). You have implementations of MAC such 
as TOMOYO and SELinux.

Given that these mechanisms are all implemented in the kernel, there should be 
a strong separation between user space and kernel space. The user should be 
able to request services from the kernel. However, the user should not be able 
to freely probe kernel memory. More importantly, the user should not be able to
 make arbitrary changes to the kernel address space.

6 Can Root Be Prevented From Having Complete Memory Access?
-----------------------------------------------------------

As Alex mentioned, the kernel can be configured to close the obvious channels 
for the root user to access kernel memory. I'm talking about disabling 
/dev/mem, /dev/kmem, /proc/kallsyms, and the like.

Ability to insert code into kernel space should also be closed off as well, by 
disabling loadable kernel modules or by requiring signed kernel modules. If 
there are non-standard channels for injecting code into the kernel like kernel 
exploits, that is something that will need to be addressed as well. (If you 
know of projects dealing with this, I am extremely interested).

As for cold-boot or reset attacks, TXT actually handles that. Specifically, on 
TXT-enabled systems, the firmware is supposed to detect reset attacks and scrub
the memory for you. There is a special "Secrets" flag that is set by the OS to
indicate that there are secrets stored in memory. During a graceful shut-down, 
this flag is reset. In the case of a reset attack, the flag is not reset. In 
that case, a component called the BIOS ACM clears the memory or assures that 
the BIOS scrubs the memory. This mechanism can be a bit more complicated and
described in greater detail in this book:

http://www.apress.com/9781430261483

Whether or not this is actually enabled with tboot/Linux and how it is used, I 
don't know.

Lastly, with coming technologies like Software Guard Extensions from Intel, it 
should become safer to store secrets in memory. From what I understand, you 
would even be able to prevent the kernel from freely probing user memory. 

7 Levels of Protection
---------------------

Physical access has different levels.
0)  You are at the mouse and keyboard of the system
1)  You can insert a USB thumb drive
2)  You can power cycle the system
3)  You can open the box and reset the pin to reset the BIOS password
4)  You can take out the disk and stick it into another machine and perform 
    some form of modification or forensics.
5)  You can probe the system memory externally at run time with a debugger
6)  You can do differential power analysis on the hardware
7)  You can take any chip apart and analyze it with an electron microscope. 
    (I've been told that this is something people actually do.)

Each additional level of access requires more time and more cost. Just because 
you can't protect against level-7 access, doesn't mean you don't try to protect
 against a level-4 access.

As Alex mentioned, there is a cost-benefit equation at play here. For an 
embedded application that is performing a critical task that does not require 
the same level of flexibility as a personal computer, a more locked-down 
configuration is acceptable if it can help protect against threats at a greater
 access level. In some cases, it might be more acceptable for all data to be 
lost and for the system to become bricked and unbootable than for the system 
to remain intact and under the control of an adversary.

8 Concerns About DRM
---------------------	

I use Linux on my personal laptop and I appreciate Arno's concerns about DRM. 
When I buy a computer, I expect to completely own that computer and decide what
 runs on it. The idea that the OEM and software provider can collude and 
connive to keep me from doing anything with my computer is absolutely 
disgusting to me. I buy it, I own it, I do whatever the hey I want with it.
 
That being said, I don't really have similar expectations about appliances like
 washing machines, TVs, or cars. (I'm pretty sure I'll void the warranties if I
 attempted to install Linux on them ;) )
 
----------------------

Thank you for taking the time to read this far. I would appreciate your 
feedback, suggestions, and thoughts.

regards,

Safayet

-----Original Message-----
From: Milan Broz [mailto:gmazyland@gmail.com] 
Sent: Sunday, December 14, 2014 1:10 PM
To: Ahmed, Safayet (GE Global Research); dm-crypt@saout.de
Subject: Re: [dm-crypt] Kernel Keyring Service

Hi,

On 12/12/2014 05:23 PM, 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.

...

As Alasdair said, this was discussed long time ago but never realized.

(Please do not forget that main FDE threat model is covering offline system only and there are a lot of other attack vectors.
If we allow attacker tampering with hw or access the system on administrator level nothing will help here.) 

But what storing key in keyring solves now? There are still issues

1) Key is still "open" in kernel memory just elsewhere

In current system the key resides in memory directly, not only in dmcrypt but also in all crypto API providers (it must be there if the encryption is done by CPU).

Removing key from dmcrypt structure is possible but with crypto provider it is not so easy.

So to make it at least some sense you have to use some crypto provider system which does not store key in memory.

No such generic provider is in upstream kernel.

(We are talking about designs like TreVisor/TRESOR, Loop amnesia and similar.
These will be never usable for generic configurations and architectures.)

2) Key must be transferred anyway

Currently the key is sent into dmcrypt in plain form in ioctl and only root can do this. This path was audited and properly wipes all buffers once the key is not needed.
(And yes, this is not coolest design but it is simple.)

Replacing it with transfer from kernel keyring will just move this inside kernel but removes the KISS principle here.

(On the other side, if we have one day non-root private device-mapper devices, keyring could help to properly isolate keys among users of these private dmcrypt devices.)

3) We do not have proper userspace support

If you see how the LUKS is designed, it processes volume key in userspace decrypted from keyslot. So it means redesigning keyslot operations.
(At least it means to add another level of key-hierarchy which covers keyring operations with "encrypted keys".)

I would like to see that instead of keyslots we have configurable key references (IOW it stores some unique ID of key stored in some token, keyring or whatever instead of directly encrypted volume key).
But we do not have such system yet.

I know that kernel part is kind of independent to this but without thinking how to integrate it to LUKS it does not make much sense.


So, I think using keyring is doable but I do not see it as a thing which primarily improves security.

I see it as logic separation of functions instead (keyring handles keys, dmcrypt block encryption). And as such it should be implemented one day.

Thanks,
Milan

Re: [dm-crypt] Kernel Keyring Service

[Arno Wagner]

Better a later, but well thought out pice ;-)

That said, I thing we have both a fundamental philosophical 
difference and an issue where your and my professional opinions 
strongly diverge.

Let me prefix that with the limitation that I am mostly talking 
about the general case. I will make some comments on your scenario
as well.

Ad 5) 
First, I very much believe that root not only should have access to
everything, I believe it is necessary to allow reliable and secure
operation of infrastructure. Sure, in the washing machine scenario
(or often these days a similar "car" scenario), you do not get root 
access, but your service technician becomes severely limited if
he does not. Then there is the little problem of incident management:
If you can be locked out from things, then that is a mechanism that
an attacker can use to prevent you from finding out that you were
attacked in the first place and from doing anything about it. 

Ad 1)
Your root user is remote. That is fine. But do you really need the 
root user to be locked out of some things in your scenario? My
experience would suggest that you need to give even more power to
root in this scenario, like doing a hard reset or power-cycles,
not less.

Ad 3) If the attacker gets root, he can just copy the decrypted
disk. No need to mess with the kernel or the decryption-key at all.
Or is your scenario one where you deploy the same key to multiple
instances of this device and hence the key itself still offers
added value after a compromise of only one of these devices? 
That would be bad... (See also FAQ Item 1.2 under 
"CLONING/IMAGING and FAQ Item 6.15) 

I think the threat and attack modelling needs more detail. 

Ad 6) I do not believe a root user can be prevented from getting 
access to everything on Linux. There are just to many things 
tied to the assumption that root can do everything and far 
too many holes to plug. As the same time, I do think even 
trying is a waste of time. What you want is a locked-down 
special-purpose OS that was created with the idea of root
not getting full access from the ground up and including 
all libraries, tools, compilers, kernel and all other code. 

This can be done, but Linux is not the platform for it. Maybe 
QNX can do this, they have some "zone" concept and I expect at
least two different levels of "root", one within the zone and 
one overall. 

Also, if you really need to prevent an attacker with physical 
access from getting the keys out of the machine then you are 
screwed. The only devices that can offer a reasonable assurance
of that are HSMs (Hardware Security Modules) and they are $50'000
and up per piece. These are typically 19" boxes with independent
power for a while, lots of sensors that detect intrusion, sturdy
cases, backup mechanisms, etc. 

A TPM will _not_ help at all as a TPM cannot do anything itself, 
it has to hand out the keys for things like disk encryption to the 
actual, unsecured (against an attacker with hardware-access) CPU. 
Some more advanced HSMs can do disk encryption by themselves, and
that is the only way to get disk-encryption where the key is secure
against an attacker with physical access.

Yes, I know that is inconvenient. But even things like secure,
encrypted boot processes with (partially) secure CPUs can be 
hacked. Look for example at "Hacking the Xbox" by Bunny Huang
or the time it takes for a new iPhone or Android version to get 
rooted. "Secure boot" is a fantasy on general-purpose hardware
with general-purpose OSes and even mostly a fantasy on specially
secured devices with "secure" hardware and fully "protected"
boot process. 


That said, if your scanario is that you must prevent an instance
compromise (single device) being equal to a group compomise,
the only feasible way is to have individual keys on each device
and to force the attacker to attack the keys all individually. 
Yes, that makes service harder, but there really seems to be no way 
around that at the current state of technology. 

I frankly do not expect the situation to get better anytime soon and 
it may get worse instead. On the other hand, storing a few million 
keys and selecting the right one when doing remote maintenance is 
not that hard. Then you only have to make sure the key-store on your
side does not get compromised. Unless you are as terminally stupid
as RSA with SecureID, this is not that hard to do either. Hell, you 
could have each key on a phycial card and read it in via a 
barcode-scanner if you need to do maintenance acceess. (Depends on 
the frequency of maintenance access, how many places it is being done 
from, how trustworthy the people doing it are, etc. There is a strong
trade-off between security and convenience here.) You still need to
secure the infrastructure you do access from very carefully. Probably
a fully isolated network that allows only tunnels to the devices to be 
maintained and protects itself from attacks comming fromt thise devices 
is needed.
  
And yes, none of this is cheap or simple. And forget about getting 
this secure without competent outside review.


Gr"usse,
Arno




On Wed, Dec 17, 2014 at 17:22:50 CET, Ahmed, Safayet (GE Global Research) wrote:
> I apologize for the delay in my reply. Thanks to everyone for the really 
> informative and insightful discussion. Also, I apologize for the length of this
>  e-mail, but I tried to address all the concerns that were raised.
> 
>     1 Intended Application
>     2 Intended Stack
>     3 One Possible Attack Scenario
>     4 What I'm Interested In
>     5 Should Root Be Allowed to Access Everything Including Kernel Memory?
>     6 Can Root Be Prevented From Having Complete Memory Access?
>     7 Levels of Protection
>     8 Concerns About DRM
> 
> 1 Intended Application
> ----------------------
> 
> My target application is an embedded system that runs without direct or
> significant user intervention like washing machines, locomotives, and
> power generators.  It is possible that with time, the target platform will
> require updates to various software components.  However, the
> administrator that has the ability to make persistent changes to the
> system is remote and not local.
>  
> 2 Intended Stack
> -----------------
> 
> For the intended application, I am considering a stack that is similar to
> what Alex mentioned.  The idea is to establish a chain of trust that is
> rooted in hardware.  With Intel TXT, the BIOS ACM measures the BIOS, the
> BIOS measures the BIOS configuration and boot loader.  Eventually, the
> kernel and initramfs are measured.  By "measured", I mean that a hash of
> the component is computed and extended into a Platform Configuration
> Register (PCR) in the TPM.
> 
> Similarly, Secure Boot is configured to ensure that only a trusted GRUB
> image can run, and in turn, GRUB security mechanisms are enabled to ensure
> that only signed components (kernel and initramfs image) can be loaded
> into memory for boot.
> 
> Once a trusted kernel image is up and running with the trusted kernel
> arguments and a trusted initramfs image, the kernel is responsible for
> protecting user land (I'm talking about the mechanisms similar to what is
> described in "Documentation/security/" in the kernel source.  LSMs and
> all).
>  
> Stepping back, provided that the system comes up in this trusted
> environment, it should have access to the disk.  If trust is not
> established, there should be no access.  The trustworthiness of the
> environment is established through the PCR values mentioned earlier.  So
> the disk-encryption key should be locked to PCR values in the TPM.
>  
> 3 One Possible Attack Scenario
> ------------------------------
> 
> The disk-encryption key being present in kernel space is necessary and
> acceptable.  I am more concerned about the key being exposed in plain text
> to user space.  I disagree with the idea that the root user should have
> access to kernel memory.  I address this in greater detail further below.
> 
> To understand my concerns, consider the following scenario:
> 
>     Once the system boots under a trusted configuration, if an adversary
>     is able to get root-level access from user space, this adversary can
>     get the volume key.  Then, the adversary can access the disk off line
>     from an untrusted configuration.  The adversary already has the volume
>     key and does not need the correct values in the PCR to access the
>     disk.  Then, the disk can be accessed from any compromised
>     configuration.
>     
> 4 What I'm Interested In
> ------------------------
> 
> I am primarily interested in disk encryption through dm-crypt alone. LUKS
> is for managing the volume key with multiple user pass phrases.  LUKS does
> not offer much in the use case I described above since the system is
> expected to boot without interacting with a user.
> 
> As Milan mentioned, the kernel part is independent and I don't really see
> why dm-crypt has to be tightly tied to LUKS.  Instead, I would like to be
> able to pass the volume key directly to dm-crypt in kernel space and
> ensure that that key is never exposed.
> 
> As I had mentioned in a previous email, the kernel key-ring services are
> already used to import and manage keys for IMA, EVM, and ecryptfs.  These
> kernel services are directly accessed through a number of system calls. 
> Also you have "keyutils" to access these services from a shell.  It makes
> sense to me for all keys including the dm-crypt keys to be managed through
> this single interface rather than maintaining a separate interface for
> dm-crypt keys.
> 
> 5 Should Root Be Allowed to Access Everything Including Kernel Memory?
> ----------------------------------------------------------------------
> 
> I don't believe so. The separation between root user and non-root user is
> only a single defense mechanism.  The idea that "if root is compromised,
> the platform is completely compromised" is not acceptable.
>  
> From what I understand, you always see examples of
> arc-injection/code-injection attacks that allow an adversary to compromise
> and take over an application.  Then, an adversary is free to pursue
> additional avenues for escalation of privilege.  Even with privileged
> access, this access should be within the confines of a controlled, trusted
> environment.
> 
> There are already a number of mechanisms that allow the Linux kernel to be
> booted in a way that limits what root can do.  You can limit what binaries
> can be executed (even by root) with IMA appraisal.  Alex already mentioned
> "capabilities" (Capcium security model).  You have implementations of MAC
> such as TOMOYO and SELinux.
> 
> Given that these mechanisms are all implemented in the kernel, there
> should be a strong separation between user space and kernel space.  The
> user should be able to request services from the kernel.  However, the
> user should not be able to freely probe kernel memory.  More importantly,
> the user should not be able to make arbitrary changes to the kernel
> address space.
> 
> 6 Can Root Be Prevented From Having Complete Memory Access?
> -----------------------------------------------------------
> 
> As Alex mentioned, the kernel can be configured to close the obvious
> channels for the root user to access kernel memory.  I'm talking about
> disabling /dev/mem, /dev/kmem, /proc/kallsyms, and the like.
> 
> Ability to insert code into kernel space should also be closed off as
> well, by disabling loadable kernel modules or by requiring signed kernel
> modules.  If there are non-standard channels for injecting code into the
> kernel like kernel exploits, that is something that will need to be
> addressed as well.  (If you know of projects dealing with this, I am
> extremely interested).
> 
> As for cold-boot or reset attacks, TXT actually handles that.
> Specifically, on TXT-enabled systems, the firmware is supposed to detect
> reset attacks and scrub the memory for you.  There is a special "Secrets"
> flag that is set by the OS to indicate that there are secrets stored in
> memory.  During a graceful shut-down, this flag is reset.  In the case of
> a reset attack, the flag is not reset.  In that case, a component called
> the BIOS ACM clears the memory or assures that the BIOS scrubs the memory. 
> This mechanism can be a bit more complicated and described in greater
> detail in this book:
> 
> http://www.apress.com/9781430261483
> 
> Whether or not this is actually enabled with tboot/Linux and how it is
> used, I don't know.
> 
> Lastly, with coming technologies like Software Guard Extensions from
> Intel, it should become safer to store secrets in memory.  From what I
> understand, you would even be able to prevent the kernel from freely
> probing user memory.
> 
> 7 Levels of Protection
> ---------------------
> 
> Physical access has different levels.
> 0)  You are at the mouse and keyboard of the system
> 1)  You can insert a USB thumb drive
> 2)  You can power cycle the system
> 3)  You can open the box and reset the pin to reset the BIOS password
> 4)  You can take out the disk and stick it into another machine and perform 
>     some form of modification or forensics.
> 5)  You can probe the system memory externally at run time with a debugger
> 6)  You can do differential power analysis on the hardware
> 7)  You can take any chip apart and analyze it with an electron microscope. 
>     (I've been told that this is something people actually do.)
> 
> Each additional level of access requires more time and more cost. Just because 
> you can't protect against level-7 access, doesn't mean you don't try to protect
>  against a level-4 access.
> 
> As Alex mentioned, there is a cost-benefit equation at play here. For an
> embedded application that is performing a critical task that does not
> require the same level of flexibility as a personal computer, a more
> locked-down configuration is acceptable if it can help protect against
> threats at a greater access level.  In some cases, it might be more
> acceptable for all data to be lost and for the system to become bricked
> and unbootable than for the system to remain intact and under the control
> of an adversary.
> 
> 8 Concerns About DRM
> ---------------------	
> 
> I use Linux on my personal laptop and I appreciate Arno's concerns about
> DRM.  When I buy a computer, I expect to completely own that computer and
> decide what runs on it.  The idea that the OEM and software provider can
> collude and connive to keep me from doing anything with my computer is
> absolutely disgusting to me.  I buy it, I own it, I do whatever the hey I
> want with it.
>  
> That being said, I don't really have similar expectations about appliances
> like washing machines, TVs, or cars.  (I'm pretty sure I'll void the
> warranties if I attempted to install Linux on them ;) )
>  
> ----------------------
> 
> Thank you for taking the time to read this far. I would appreciate your 
> feedback, suggestions, and thoughts.
> 
> regards,
> 
> Safayet
> 
> -----Original Message-----
> From: Milan Broz [mailto:gmazyland@gmail.com] 
> Sent: Sunday, December 14, 2014 1:10 PM
> To: Ahmed, Safayet (GE Global Research); dm-crypt@saout.de
> Subject: Re: [dm-crypt] Kernel Keyring Service
> 
> Hi,
> 
> On 12/12/2014 05:23 PM, 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.
> 
> ...
> 
> As Alasdair said, this was discussed long time ago but never realized.
> 
> (Please do not forget that main FDE threat model is covering offline system only and there are a lot of other attack vectors.
> If we allow attacker tampering with hw or access the system on administrator level nothing will help here.) 
> 
> But what storing key in keyring solves now? There are still issues
> 
> 1) Key is still "open" in kernel memory just elsewhere
> 
> In current system the key resides in memory directly, not only in dmcrypt but also in all crypto API providers (it must be there if the encryption is done by CPU).
> 
> Removing key from dmcrypt structure is possible but with crypto provider it is not so easy.
> 
> So to make it at least some sense you have to use some crypto provider system which does not store key in memory.
> 
> No such generic provider is in upstream kernel.
> 
> (We are talking about designs like TreVisor/TRESOR, Loop amnesia and similar.
> These will be never usable for generic configurations and architectures.)
> 
> 2) Key must be transferred anyway
> 
> Currently the key is sent into dmcrypt in plain form in ioctl and only root can do this. This path was audited and properly wipes all buffers once the key is not needed.
> (And yes, this is not coolest design but it is simple.)
> 
> Replacing it with transfer from kernel keyring will just move this inside kernel but removes the KISS principle here.
> 
> (On the other side, if we have one day non-root private device-mapper devices, keyring could help to properly isolate keys among users of these private dmcrypt devices.)
> 
> 3) We do not have proper userspace support
> 
> If you see how the LUKS is designed, it processes volume key in userspace decrypted from keyslot. So it means redesigning keyslot operations.
> (At least it means to add another level of key-hierarchy which covers keyring operations with "encrypted keys".)
> 
> I would like to see that instead of keyslots we have configurable key references (IOW it stores some unique ID of key stored in some token, keyring or whatever instead of directly encrypted volume key).
> But we do not have such system yet.
> 
> I know that kernel part is kind of independent to this but without thinking how to integrate it to LUKS it does not make much sense.
> 
> 
> So, I think using keyring is doable but I do not see it as a thing which primarily improves security.
> 
> I see it as logic separation of functions instead (keyring handles keys, dmcrypt block encryption). And as such it should be implemented one day.
> 
> Thanks,
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

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