[PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Lakshmi]

The motive behind this patch series is to measure the public key
of keys in BuiltIn_Trusted_Keys keyring to IMA log.

The kernel could be built with the config parameter
CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY enabled.
If this is done only those "IMA Signer Keys" that are signed by a key in
the "BuiltIn Trusted Keys" or the "Secondary Trusted Keys" can be added
to the "IMA Keyring".

In other words, "IMA Signer Keys" are attested by the "Trusted Keys"
on the client machines if the above config parameter is enabled.

IMA will enumerate the keys in the Trusted Keys keyring, and measure
them in the IMA log. On file read, IMA will validate the signature of
the system files using "IMA Signer Key" present in "IMA Keyring".

An attestation service would receive the "Trusted Keys" from
a trusted source (which is different from the client machines it is
attesting). The service would compare the Trusted Keys reported by
the client with the list of known Trusted Keys. A client would be
marked trusted by the service if and only if the keys reported
by the client are all trusted.

Using the above approach the attestation service will be attesting
the "IMA Signer" while the clients attest the IMA Signature of
the system files. This enables the service to attest the client
machines by maintaining only a list of "Trusted Keys". These keys
change much less frequently than "IMA Signer Keys". It also frees
the service from having to maintain the "Hash of System Files"
which would change very frequently. This approach would significantly
reduce the maintenance cost of the service with respect to the data used
for attesting clients.

To achieve the above the patch series does the following:
   - Adds a new method in asymmetric_key_subtype to query
     the public key of the given key
   - Enumerate the keys in "BuiltIn Trusted Keys" and measure
     them to IMA log.

Lakshmi (2):
   Added a new interface method namely query_public_key to
     asymmetric_key_subtype interface
   Measure keys in BuiltIn Trusted Keys keyring

  Documentation/crypto/asymmetric-keys.txt |  1 +
  certs/system_keyring.c                   |  7 ++
  crypto/asymmetric_keys/public_key.c      |  7 ++
  crypto/asymmetric_keys/signature.c       | 24 +++++++
  include/crypto/public_key.h              |  1 +
  include/keys/asymmetric-subtype.h        |  3 +
  include/keys/system_keyring.h            |  9 +++
  include/linux/key.h                      | 32 +++++++++
  security/integrity/digsig.c              | 58 +++++++++++++++++
  security/integrity/ima/Kconfig           |  9 +++
  security/integrity/ima/ima_init.c        | 62 ++++++++++++++++++
  security/integrity/integrity.h           | 25 ++++++++
  security/keys/keyring.c                  | 82 ++++++++++++++++++++++++
  13 files changed, 320 insertions(+)

-- 
2.17.1

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Mimi Zohar]

On Wed, 2019-06-05 at 17:16 -0700, Lakshmi wrote:
> The motive behind this patch series is to measure the public key
> of keys in BuiltIn_Trusted_Keys keyring to IMA log.
> 
> The kernel could be built with the config parameter
> CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY enabled.
> If this is done only those "IMA Signer Keys" that are signed by a key in
> the "BuiltIn Trusted Keys" or the "Secondary Trusted Keys" can be added
> to the "IMA Keyring".
> 
> In other words, "IMA Signer Keys" are attested by the "Trusted Keys"
> on the client machines if the above config parameter is enabled.
> 
> IMA will enumerate the keys in the Trusted Keys keyring, and measure
> them in the IMA log. On file read, IMA will validate the signature of
> the system files using "IMA Signer Key" present in "IMA Keyring".
> 
> An attestation service would receive the "Trusted Keys" from
> a trusted source (which is different from the client machines it is
> attesting). The service would compare the Trusted Keys reported by
> the client with the list of known Trusted Keys. A client would be
> marked trusted by the service if and only if the keys reported
> by the client are all trusted.
> 
> Using the above approach the attestation service will be attesting
> the "IMA Signer" while the clients attest the IMA Signature of
> the system files. This enables the service to attest the client
> machines by maintaining only a list of "Trusted Keys". These keys
> change much less frequently than "IMA Signer Keys". It also frees
> the service from having to maintain the "Hash of System Files"
> which would change very frequently. This approach would significantly
> reduce the maintenance cost of the service with respect to the data used
> for attesting clients.

Instead of measuring all the files in policy, Roberto's "digest lists"
proposed patch set measures only "unknown" files.  Why bother with all
those messy measurements?!

In your use case scenario, will the measurement list only contain the builtin and secondary keys?

Mimi

> 
> To achieve the above the patch series does the following:
>    - Adds a new method in asymmetric_key_subtype to query
>      the public key of the given key
>    - Enumerate the keys in "BuiltIn Trusted Keys" and measure
>      them to IMA log.
> 
> Lakshmi (2):
>    Added a new interface method namely query_public_key to
>      asymmetric_key_subtype interface
>    Measure keys in BuiltIn Trusted Keys keyring
> 
>   Documentation/crypto/asymmetric-keys.txt |  1 +
>   certs/system_keyring.c                   |  7 ++
>   crypto/asymmetric_keys/public_key.c      |  7 ++
>   crypto/asymmetric_keys/signature.c       | 24 +++++++
>   include/crypto/public_key.h              |  1 +
>   include/keys/asymmetric-subtype.h        |  3 +
>   include/keys/system_keyring.h            |  9 +++
>   include/linux/key.h                      | 32 +++++++++
>   security/integrity/digsig.c              | 58 +++++++++++++++++
>   security/integrity/ima/Kconfig           |  9 +++
>   security/integrity/ima/ima_init.c        | 62 ++++++++++++++++++
>   security/integrity/integrity.h           | 25 ++++++++
>   security/keys/keyring.c                  | 82 ++++++++++++++++++++++++
>   13 files changed, 320 insertions(+)
> 

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Lakshmi]

On 6/6/19 5:44 AM, Mimi Zohar wrote:
> 
> Instead of measuring all the files in policy, Roberto's "digest lists"
> proposed patch set measures only "unknown" files.  Why bother with all
> those messy measurements?!

I agree. But in our use case scenario, we want the attestation service 
to know who signed the system files and leave the task of validating the 
file signature to the clients.

Essentially, in our approach we are measuring the "signer".

> In your use case scenario, will the measurement list only contain the builtin and secondary keys?
> 
> Mimi

In my implementation I am measuring the builtin keys. Since any key 
added to the secondary keyring also needs to be signed by a key in the 
builtin keyring, I feel measuring only "builtin keys" is sufficient.

But I am open to the suggestion of measuring secondary keys as well. 
Please let me know if you think that is a must.

Thanks,
  -lakshmi

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Ken Goldman]

On 6/5/2019 8:16 PM, Lakshmi wrote:
> The motive behind this patch series is to measure the public key
> of keys in BuiltIn_Trusted_Keys keyring to IMA log.

I don't understand the motivation behind this proposal.  Below, you 
explain what you do.  Can you explain why?

I.e., I don't see a problem with the proposal, but what is the benefit?

> The kernel could be built with the config parameter
> CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY enabled.
> If this is done only those "IMA Signer Keys" that are signed by a key in
> the "BuiltIn Trusted Keys" or the "Secondary Trusted Keys" can be added
> to the "IMA Keyring".
> 
> In other words, "IMA Signer Keys" are attested by the "Trusted Keys"
> on the client machines if the above config parameter is enabled.
> 
> IMA will enumerate the keys in the Trusted Keys keyring, and measure
> them in the IMA log. On file read, IMA will validate the signature of
> the system files using "IMA Signer Key" present in "IMA Keyring".
> 
> An attestation service would receive the "Trusted Keys" from
> a trusted source (which is different from the client machines it is
> attesting). The service would compare the Trusted Keys reported by
> the client with the list of known Trusted Keys. A client would be
> marked trusted by the service if and only if the keys reported
> by the client are all trusted.

Why is this important?  What is gained by measuring the keys on the
built-in keyring?  The IMA log already measures [a pointer to] the
IMA keys used for signature verification.  Why does the service care 
what keys were used to install the IMA keys?

> Using the above approach the attestation service will be attesting
> the "IMA Signer" while the clients attest the IMA Signature of
> the system files. This enables the service to attest the client
> machines by maintaining only a list of "Trusted Keys". These keys
> change much less frequently than "IMA Signer Keys". It also frees
> the service from having to maintain the "Hash of System Files"
> which would change very frequently. This approach would significantly
> reduce the maintenance cost of the service with respect to the data used
> for attesting clients.

I don't understand this reasoning.

To me, there is a difference between signed files and trusted files. 
E.g., an old version may be signed, but it is no longer trusted.

In other words, the service wants to know all files that have run, not 
just whether they are signed.

Further, the service also wants to know files that were blocked from 
running, either because of no signature, a signature with an untrusted 
IMA key, or a bad signature.  I.e., the service needs the entire IMA 
log, not just the keys used to install the keys used to locally verify 
the signatures.

While the built-in keys may change less frequently that the IMA keys, 
both are likely to be stable.  I.e., is this proposal to provide an 
additional security benefit, or is it to improve performance?

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Lakshmi]

On 6/7/19 7:14 AM, Ken Goldman wrote:

> 
> Why is this important?  What is gained by measuring the keys on the
> built-in keyring?  The IMA log already measures [a pointer to] the
> IMA keys used for signature verification.  Why does the service care 
> what keys were used to install the IMA keys?

By measuring the built-in keyring, the service knows whether or not the 
key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key 
validates the file signatures on the client, the built-in key validates 
the IMA key(s).

By knowing what keys were used to install the IMA key(s) the service 
knows whether or not to trust the signature validation performed by IMA 
on the client.

> 
> I don't understand this reasoning.
> 
> To me, there is a difference between signed files and trusted files. 
> E.g., an old version may be signed, but it is no longer trusted. >
> In other words, the service wants to know all files that have run, not 
> just whether they are signed.

The service will receive the entire IMA log - the entries that show what 
system files were loaded, the IMA signature, etc. My change additionally 
provides measurement on the signer (which key(s) were used to install 
the keys in IMA keyring). Together this data enables the service to 
determine whether the files on the client were signed and who the signer 
is. The service can then decide whether the client is running files that 
are trusted.

> 
> Further, the service also wants to know files that were blocked from 
> running, either because of no signature, a signature with an untrusted 
> IMA key, or a bad signature.  I.e., the service needs the entire IMA 
> log, not just the keys used to install the keys used to locally verify 
> the signatures.

Like I have stated above, the change I am making is adding more data 
(information on built-in keys) to what IMA log already provides".

My proposal is not to replace the current IMA log with just data on 
"built-in keys".

Also, want to clarify that we do not want the service to also locally 
verify the signatures. To do that the service needs to maintain the 
signed file hashes of all the files and all the versions of each of 
those files - That is an high overhead approach.

Instead, we let the client do the signature validation and on the 
service just validate who signed those files.

> 
> While the built-in keys may change less frequently that the IMA keys, 
> both are likely to be stable.  I.e., is this proposal to provide an 
> additional security benefit, or is it to improve performance?

The proposal enables the service to validate that the file signature of 
the files on the client were created by "trusted signer". So it provides 
additional security benefit and at the same time reduces the maintenance 
overhead in the service - by enabling it to just keep track of "Known 
good trusted keys" which change less frequently.

I hope I have answered all of your questions\concerns.

Thanks,
  -lakshmi

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Jordan Hand]

On 6/7/19 7:14 AM, Ken Goldman wrote:
> On 6/5/2019 8:16 PM, Lakshmi wrote:
>> The kernel could be built with the config parameter
>> CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY enabled.
>> If this is done only those "IMA Signer Keys" that are signed by a key in
>> the "BuiltIn Trusted Keys" or the "Secondary Trusted Keys" can be added
>> to the "IMA Keyring".
>>
>> In other words, "IMA Signer Keys" are attested by the "Trusted Keys"
>> on the client machines if the above config parameter is enabled.
>>
>> IMA will enumerate the keys in the Trusted Keys keyring, and measure
>> them in the IMA log. On file read, IMA will validate the signature of
>> the system files using "IMA Signer Key" present in "IMA Keyring".
>>
>> An attestation service would receive the "Trusted Keys" from
>> a trusted source (which is different from the client machines it is
>> attesting). The service would compare the Trusted Keys reported by
>> the client with the list of known Trusted Keys. A client would be
>> marked trusted by the service if and only if the keys reported
>> by the client are all trusted.
> 
> Why is this important?  What is gained by measuring the keys on the
> built-in keyring?  The IMA log already measures [a pointer to] the
> IMA keys used for signature verification.  Why does the service care 
> what keys were used to install the IMA keys?
> 
>> Using the above approach the attestation service will be attesting
>> the "IMA Signer" while the clients attest the IMA Signature of
>> the system files. This enables the service to attest the client
>> machines by maintaining only a list of "Trusted Keys". These keys
>> change much less frequently than "IMA Signer Keys". It also frees
>> the service from having to maintain the "Hash of System Files"
>> which would change very frequently. This approach would significantly
>> reduce the maintenance cost of the service with respect to the data used
>> for attesting clients.
> 
> I don't understand this reasoning.
> 
> To me, there is a difference between signed files and trusted files. 
> E.g., an old version may be signed, but it is no longer trusted.
> 
> In other words, the service wants to know all files that have run, not 
> just whether they are signed

Thought I'd jump in this conversation to see if I can clarify what I see 
as the value of this patch set.

At a certain point, keeping a list of all known-good (or known-bad) 
hashes becomes infeasible. We could probably disagree about at what 
scale this happens but I think we could agree that eventually this 
happens (let me know if you still disagree with this assertion). So at 
this point you likely need to rely on a few things:

(1) is the file >= <known good version>. This allows you to forbid any 
kernel version before a vulnerability was fixed.

(2) Was it signed with a good, trusted, production key.

You can sort of do this today by using the keyid. The issues with this 
are (a) collision (though the chance may be pretty remote. I don't have 
the crypto expertise to make an empirical call on that) and (b) you need 
to know all the possible signing keys in the service.

Again, once you cross a certain scale threshold, signing/deployment is 
so automated that the leaf key could change at any time, leaving your 
service in the dark about new keys. You could automatically add new 
trusted keys to the service but it depends on the service environment 
and how much you want to automate what the service trusts.

So what does measuring the keyring do? It allows you to put long-lived 
trusted CAs in .builtin_trusted_keys. On the service if you trust the CA 
and you trust the running kernel to do the right thing during key 
enrollment, you can trust that loaded files are properly signed.

> 
> Further, the service also wants to know files that were blocked from 
> running, either because of no signature, a signature with an untrusted 
> IMA key, or a bad signature.  I.e., the service needs the entire IMA 
> log, not just the keys used to install the keys used to locally verify 
> the signatures.

In UEFI measurements, the goal is usually to allow the service to decide 
what is important and what isn't. For example, UEFI measures the file 
hashes of efi binaries as well as the db (list of keys being used to 
validate efi signatures). The service is free to use one, both, or 
neither depending on its security model.

Obviously Linux is not UEFI and "they do it in UEFI" is not a design 
justification by itself, just though I'd provide that as a frame of 
reference to explain the reasoning.

> 
> While the built-in keys may change less frequently that the IMA keys, 
> both are likely to be stable.  I.e., is this proposal to provide an 
> additional security benefit, or is it to improve performance?

In my opinion the biggest benefit here is to improve manageability of 
keys. You can put trust in CAs (similar to what browsers do with SSL 
certs) and you don't need to update the service when leaf keys change, 
as they're bound to do.

-Jordan

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Lakshmi]

On 6/7/19 10:15 AM, Lakshmi wrote:
> On 6/7/19 7:14 AM, Ken Goldman wrote:
> 
>>
>> Why is this important?  What is gained by measuring the keys on the
>> built-in keyring?  The IMA log already measures [a pointer to] the
>> IMA keys used for signature verification.  Why does the service care 
>> what keys were used to install the IMA keys?
> 
> By measuring the built-in keyring, the service knows whether or not the 
> key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key 
> validates the file signatures on the client, the built-in key validates 
> the IMA key(s).
> 
> By knowing what keys were used to install the IMA key(s) the service 
> knows whether or not to trust the signature validation performed by IMA 
> on the client.

Hi Ken\Mimi,

Please let me know if you have more questions\concerns about this approach.

If the high level design is acceptable, please review the code changes 
and provide feedback\comments.

Thanks,
  -lakshmi

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Mimi Zohar]

On Fri, 2019-06-07 at 10:15 -0700, Lakshmi wrote:
> On 6/7/19 7:14 AM, Ken Goldman wrote:
> 
> > 
> > Why is this important?  What is gained by measuring the keys on the
> > built-in keyring?  The IMA log already measures [a pointer to] the
> > IMA keys used for signature verification.  Why does the service care 
> > what keys were used to install the IMA keys?
> 
> By measuring the built-in keyring, the service knows whether or not the 
> key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key 
> validates the file signatures on the client, the built-in key validates 
> the IMA key(s).
> 
> By knowing what keys were used to install the IMA key(s) the service 
> knows whether or not to trust the signature validation performed by IMA 
> on the client.
> 
> > 
> > I don't understand this reasoning.
> > 
> > To me, there is a difference between signed files and trusted files. 
> > E.g., an old version may be signed, but it is no longer trusted. >
> > In other words, the service wants to know all files that have run, not 
> > just whether they are signed.
> 
> The service will receive the entire IMA log - the entries that show what 
> system files were loaded, the IMA signature, etc. My change additionally 
> provides measurement on the signer (which key(s) were used to install 
> the keys in IMA keyring). Together this data enables the service to 
> determine whether the files on the client were signed and who the signer 
> is. The service can then decide whether the client is running files that 
> are trusted.
> 
> > 
> > Further, the service also wants to know files that were blocked from 
> > running, either because of no signature, a signature with an untrusted 
> > IMA key, or a bad signature.  I.e., the service needs the entire IMA 
> > log, not just the keys used to install the keys used to locally verify 
> > the signatures.
> 
> Like I have stated above, the change I am making is adding more data 
> (information on built-in keys) to what IMA log already provides".
> 
> My proposal is not to replace the current IMA log with just data on 
> "built-in keys".
> 
> Also, want to clarify that we do not want the service to also locally 
> verify the signatures. To do that the service needs to maintain the 
> signed file hashes of all the files and all the versions of each of 
> those files - That is an high overhead approach.
> 
> Instead, we let the client do the signature validation and on the 
> service just validate who signed those files.
> 
> > 
> > While the built-in keys may change less frequently that the IMA keys, 
> > both are likely to be stable.  I.e., is this proposal to provide an 
> > additional security benefit, or is it to improve performance?
> 
> The proposal enables the service to validate that the file signature of 
> the files on the client were created by "trusted signer". So it provides 
> additional security benefit and at the same time reduces the maintenance 
> overhead in the service - by enabling it to just keep track of "Known 
> good trusted keys" which change less frequently.
> 
> I hope I have answered all of your questions\concerns.

The design of IMA from the very beginning has been to allow the system
owner to decide which keys to trust.  This is the reason that the root
of trust pivots from the pre-boot keys to the keys embedded in the
Linux kernel.  When software packages contain both the file data and
file signatures, the system owner will be able to pick and choose
which public keys to sign and load onto the IMA keyring.

This patch set might not be limiting which public keys may be loaded
onto the builtin/secondary keyrings, but by virtue of including this
information in the measurement list, the attestation service (eg. TNC)
will be able to deny access.  IMA walks a fine line in enforcing and
measuring file integrity.  This patch set breaches that fine line and
by so doing, brings back the fears of trusted computing.

Mimi

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Mimi Zohar]

On Tue, 2019-06-11 at 08:22 -0400, Mimi Zohar wrote:
> On Fri, 2019-06-07 at 10:15 -0700, Lakshmi wrote:
> > On 6/7/19 7:14 AM, Ken Goldman wrote:
> > 
> > > 
> > > Why is this important?  What is gained by measuring the keys on the
> > > built-in keyring?  The IMA log already measures [a pointer to] the
> > > IMA keys used for signature verification.  Why does the service care 
> > > what keys were used to install the IMA keys?
> > 
> > By measuring the built-in keyring, the service knows whether or not the 
> > key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key 
> > validates the file signatures on the client, the built-in key validates 
> > the IMA key(s).
> > 
> > By knowing what keys were used to install the IMA key(s) the service 
> > knows whether or not to trust the signature validation performed by IMA 
> > on the client.
> > 
> > > 
> > > I don't understand this reasoning.
> > > 
> > > To me, there is a difference between signed files and trusted files. 
> > > E.g., an old version may be signed, but it is no longer trusted. >
> > > In other words, the service wants to know all files that have run, not 
> > > just whether they are signed.
> > 
> > The service will receive the entire IMA log - the entries that show what 
> > system files were loaded, the IMA signature, etc. My change additionally 
> > provides measurement on the signer (which key(s) were used to install 
> > the keys in IMA keyring). Together this data enables the service to 
> > determine whether the files on the client were signed and who the signer 
> > is. The service can then decide whether the client is running files that 
> > are trusted.
> > 
> > > 
> > > Further, the service also wants to know files that were blocked from 
> > > running, either because of no signature, a signature with an untrusted 
> > > IMA key, or a bad signature.  I.e., the service needs the entire IMA 
> > > log, not just the keys used to install the keys used to locally verify 
> > > the signatures.
> > 
> > Like I have stated above, the change I am making is adding more data 
> > (information on built-in keys) to what IMA log already provides".
> > 
> > My proposal is not to replace the current IMA log with just data on 
> > "built-in keys".
> > 
> > Also, want to clarify that we do not want the service to also locally 
> > verify the signatures. To do that the service needs to maintain the 
> > signed file hashes of all the files and all the versions of each of 
> > those files - That is an high overhead approach.
> > 
> > Instead, we let the client do the signature validation and on the 
> > service just validate who signed those files.
> > 
> > > 
> > > While the built-in keys may change less frequently that the IMA keys, 
> > > both are likely to be stable.  I.e., is this proposal to provide an 
> > > additional security benefit, or is it to improve performance?
> > 
> > The proposal enables the service to validate that the file signature of 
> > the files on the client were created by "trusted signer". So it provides 
> > additional security benefit and at the same time reduces the maintenance 
> > overhead in the service - by enabling it to just keep track of "Known 
> > good trusted keys" which change less frequently.
> > 
> > I hope I have answered all of your questions\concerns.
> 
> The design of IMA from the very beginning has been to allow the system
> owner to decide which keys to trust.  This is the reason that the root
> of trust pivots from the pre-boot keys to the keys embedded in the
> Linux kernel.  When software packages contain both the file data and
> file signatures, the system owner will be able to pick and choose
> which public keys to sign and load onto the IMA keyring.
> 
> This patch set might not be limiting which public keys may be loaded
> onto the builtin/secondary keyrings, but by virtue of including this
> information in the measurement list, the attestation service (eg. TNC)
> will be able to deny access.  IMA walks a fine line in enforcing and
> measuring file integrity.  This patch set breaches that fine line and
> by so doing, brings back the fears of trusted computing.

Many attempts over the years were made to update grub to support
secure & trusted boot.  Richard Stallman (grudgingly) added the secure
boot callbacks, which are also being used for trusted boot.  The code
to actually do the signature verification though, as far as I'm aware,
is still not part of grub.

It also took a really long time and effort to convince Stallman that
TPMs aren't totally bad.  He's added an addendum to the wiki.[1]
 Let's try not to upset Stallman too much.

Mimi

[1] https://www.gnu.org/philosophy/can-you-trust.en.html

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Jordan Hand]

On 6/11/19 10:13 AM, Mimi Zohar wrote:
>>
>> The design of IMA from the very beginning has been to allow the system
>> owner to decide which keys to trust.  This is the reason that the root
>> of trust pivots from the pre-boot keys to the keys embedded in the
>> Linux kernel.  When software packages contain both the file data and
>> file signatures, the system owner will be able to pick and choose
>> which public keys to sign and load onto the IMA keyring.
>>
>> This patch set might not be limiting which public keys may be loaded
>> onto the builtin/secondary keyrings, but by virtue of including this
>> information in the measurement list, the attestation service (eg. TNC)
>> will be able to deny access.  IMA walks a fine line in enforcing and
>> measuring file integrity.  This patch set breaches that fine line and
>> by so doing, brings back the fears of trusted computing.


I don't understand why measuring the keyring is more restrictive. 
Currently the signature of a file can already be measured. This means 
that the service can maintain a list of allowable keys and see if the 
files are signed with any of those keys. So effectively it is already 
possible for a service to deny access to the machine based on the keys 
it trusts.

I also think validating the keys in the keyring is less restrictive than 
file-hash validation. You can say "I trust any file that the signer 
trusts". In file-hash validation you're saying "I only trust the files 
that I trust".

> 
> Many attempts over the years were made to update grub to support
> secure & trusted boot.  Richard Stallman (grudgingly) added the secure
> boot callbacks, which are also being used for trusted boot.  The code
> to actually do the signature verification though, as far as I'm aware,
> is still not part of grub.
> 
> It also took a really long time and effort to convince Stallman that
> TPMs aren't totally bad.  He's added an addendum to the wiki.[1]
>   Let's try not to upset Stallman too much.

I do understand the desire to avoid taking a step backward by pushing 
too hard. As I said above, I don't see this as more restrictive than the 
existing measurements. But you have more understanding of the history 
here so let me know if I'm missing something.

-Jordan

> 
> Mimi
> 
> [1] https://www.gnu.org/philosophy/can-you-trust.en.html
> 

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Mimi Zohar]

On Wed, 2019-06-12 at 09:47 -0700, Jordan Hand wrote:

> I don't understand why measuring the keyring is more restrictive.

It's more restrictive because of which keyring you're measuring.
 You're not measuring the IMA keyring, but the builtin keyring.

Mimi

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Ken Goldman]

On 6/7/2019 1:15 PM, Lakshmi wrote:
> On 6/7/19 7:14 AM, Ken Goldman wrote:
> 
>>
>> Why is this important?  What is gained by measuring the keys on the
>> built-in keyring?  The IMA log already measures [a pointer to] the
>> IMA keys used for signature verification.  Why does the service care 
>> what keys were used to install the IMA keys?
> 
> By measuring the built-in keyring, the service knows whether or not the 
> key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key 
> validates the file signatures on the client, the built-in key validates 
> the IMA key(s).

How will it know that?  It will know about the keys in the built-in 
keyring, but how does that say whether an IMA key is trusted?

> 
> By knowing what keys were used to install the IMA key(s) the service 
> knows whether or not to trust the signature validation performed by IMA 
> on the client.

How does that happen?

In order to trust the IMA validation, it has to attest to the code doing 
the validation, and to the IMA keys.

It already knows which IMA keys were used from the IMA log, assuming the 
IMA code is attested.

> The service will receive the entire IMA log - the entries that show what 
> system files were loaded, the IMA signature, etc. My change additionally 
> provides measurement on the signer (which key(s) were used to install 
> the keys in IMA keyring). Together this data enables the service to 
> determine whether the files on the client were signed and who the signer 
> is. The service can then decide whether the client is running files that 
> are trusted.

How does knowing the keys on the built-in keyring tell which files were 
signed?  How does it tell who the signer is?

That information (whether signed and what signed it) comes from the IMA 
log, right?

How would your design help to know whether the files being run are 
trusted?  I think that has to come out-of-band.

E.g., I can know that libfoo.so.1.2.3 is signed and who the signer is, 
but I may not trust anything older than libfoo.2.0.0.


> Like I have stated above, the change I am making is adding more data 
> (information on built-in keys) to what IMA log already provides".

Understood.  I'm trying to learn the usefulness of that data.

> 
> My proposal is not to replace the current IMA log with just data on 
> "built-in keys".
> 
> Also, want to clarify that we do not want the service to also locally 
> verify the signatures. To do that the service needs to maintain the 
> signed file hashes of all the files and all the versions of each of 
> those files - That is an high overhead approach.

Doesn't it needs those hashes anyway, to determine whether the file is 
trusted.  To me "signed with a trusted key" does not equal "trusted".

> The proposal enables the service to validate that the file signature of 
> the files on the client were created by "trusted signer". So it provides 
> additional security benefit and at the same time reduces the maintenance 
> overhead in the service - by enabling it to just keep track of "Known 
> good trusted keys" which change less frequently.

We already know who signed from the IMA keys in the IMA log.

How does knowing who was authorized to install IMA keys help?  The 
attestor still has to know out of band which IMA keys to trust, and 
which files to trust.

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Lakshmi]

On 6/17/19 10:04 AM, Ken Goldman wrote:

> How will it know that?  It will know about the keys in the built-in 
> keyring, but how does that say whether an IMA key is trusted?

The parameter CONFIG_INTEGRITY_TRUSTED_KEYRING is enabled so that key(s) 
added to the IMA keyring must be signed by a key in the system trusted 
keyring. So by knowing what keys are present in the "Built-In Trusted 
Keyring", we can know if the IMA keys are trusted or not.

>> By knowing what keys were used to install the IMA key(s) the service 
>> knows whether or not to trust the signature validation performed by 
>> IMA on the client.
> 
> How does that happen?
> 
> In order to trust the IMA validation, it has to attest to the code doing 
> the validation, and to the IMA keys.
> 
> It already knows which IMA keys were used from the IMA log, assuming the 
> IMA code is attested.

Yes - from the IMA log the service knows which IMA keys were used.
And, by knowing the keys in built-in trusted keyring, the service can 
know whether those IMA keys are trusted (because the IMA keys have to be 
signed by the key(s) in built-in trusted keyring: by enabling 
CONFIG_INTEGRITY_TRUSTED_KEYRING).

Since, the built-in keys change much less often than the IMA keys, it is 
much less maintenance overhead in the service to attest the built-in 
keys compared to attesting the IMA keys.

Due to the requirement that the IMA keys must be signed by built-in key, 
attesting the built-in key effectively attests the IMA keys as well.

> How does knowing the keys on the built-in keyring tell which files were 
> signed?  How does it tell who the signer is?
> 
> That information (whether signed and what signed it) comes from the IMA 
> log, right?
The IMA log tells the service which files were signed and which IMA key 
was used to sign those files.

My proposal does not alter (remove) any data that is currently supported 
in the IMA log. It is only adding more information in the IMA log - the 
information on the signer of the IMA signer key(s).

> How would your design help to know whether the files being run are 
> trusted?  I think that has to come out-of-band.
> 
> E.g., I can know that libfoo.so.1.2.3 is signed and who the signer is, 
> but I may not trust anything older than libfoo.2.0.0.

You are right - the fact that file older than, for example, libfoo 2.0.0 
is trusted or not is not something my proposal covers. That is not the 
goal of this proposal.

IMA log currently just conveys libfoo.1.5.6 is signed and provides 
information on the signer. Whether that version is trusted or not needs 
to be verified by the service outside of IMA.

>> Like I have stated above, the change I am making is adding more data 
>> (information on built-in keys) to what IMA log already provides".
> 
> Understood.  I'm trying to learn the usefulness of that data.

My proposal is adding information on the signer of the IMA signer key - 
that signer information is in the "Built-In Trusted Keys".

That data, in addition to the current IMA log, provides information to 
the service to determine if the IMA keys used by the clients are trusted 
or not.

> Doesn't it needs those hashes anyway, to determine whether the file is 
> trusted.  To me "signed with a trusted key" does not equal "trusted".
I agree - a file that has valid signature may not be trusted because 
that version of the file was, for instance, buggy.

The goal of my proposal is not to help the service determine whether a 
file is trusted or not - that has to be done outside of IMA.

The goal of my proposal is to convey whether the file was signed with a 
trusted key.

> We already know who signed from the IMA keys in the IMA log.
> 
> How does knowing who was authorized to install IMA keys help?  The 
> attestor still has to know out of band which IMA keys to trust, and 
> which files to trust.

By building the kernel with CONFIG_INTEGRITY_TRUSTED_KEYRING we are 
mandating that the IMA key is signed by built-in key.

So by knowing who authorized (signed) the IMA key, the service is able 
to know whether to trust the IMA key or not.

Information on the IMA key is already available in the IMA log. But 
since IMA keys change much more frequently than the "Built-In Keys", it 
is more overhead for the service to keep track of all valid IMA keys 
compared to doing the same for "Built-In keys".

Hence my proposal to include the "Built-In keys" in the IMA measurement.

Thanks,
  -lakshmi

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Matthew Garrett]

On Mon, Jun 17, 2019 at 10:05 AM Ken Goldman <kgold@linux.ibm.com> wrote:
> On 6/7/2019 1:15 PM, Lakshmi wrote:
> > By knowing what keys were used to install the IMA key(s) the service
> > knows whether or not to trust the signature validation performed by IMA
> > on the client.
>
> How does that happen?
>
> In order to trust the IMA validation, it has to attest to the code doing
> the validation, and to the IMA keys.

If you can assert that all code you've signed with your Secure Boot
signing key is trusted, and that all keys that are embedded within
code that's signed with your Secure Boot signing key are trusted, and
that all keys signed with those keys are trusted, then you just need a
mechanism to measure each component of that chain and attest to it.
This is, as an example, the default Bitlocker policy under Windows -
rather than seal the disk encryption secret to the full set of PCR
values, the secret is sealed to PCR7. If a non-Windows bootloader is
inserted into the boot process the PCR7 measurement will change (due
to it being signed with a different certificate) and the unsealing
will fail. Since Microsoft can assert that they will never sign
something that they don't trust, this avoids having to re-seal the
secret every time they update the bootloader.

> E.g., I can know that libfoo.so.1.2.3 is signed and who the signer is,
> but I may not trust anything older than libfoo.2.0.0.

If you want to construct more complex policies then you need to
examine more information :) This approach doesn't work for your case,
but if the policy concern is "I want to ensure that all code run on
this system came through my build pipeline" then you don't need to
look at individual signatures.

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Ken Goldman]

On 6/10/2019 12:57 PM, Jordan Hand wrote:
> 
> Thought I'd jump in this conversation to see if I can clarify what I see 
> as the value of this patch set.
> 
> At a certain point, keeping a list of all known-good (or known-bad) 
> hashes becomes infeasible. We could probably disagree about at what 
> scale this happens but I think we could agree that eventually this 
> happens (let me know if you still disagree with this assertion). So at 
> this point you likely need to rely on a few things:

I've seen large systems with 60,000 measurements.  Even if that goes to 
100,000, *10 for bad measurements, and *10 for future expansion, that's 
only 10M, or 320 mbytes.  That's pennies of disk space.

> 
> (1) is the file >= <known good version>. This allows you to forbid any 
> kernel version before a vulnerability was fixed.

Perhaps, but one might also exclude a newer version, either because of a 
regression, a certification, etc.

> 
> (2) Was it signed with a good, trusted, production key.
> 
> You can sort of do this today by using the keyid. The issues with this 
> are (a) collision (though the chance may be pretty remote. I don't have 
> the crypto expertise to make an empirical call on that) and (b) you need 
> to know all the possible signing keys in the service.

The 4 byte key id was probably a long term mistake, but can be fixed. 
Today, a collision is remote.  Even then, just try both keys.  Nothing 
breaks.

> 
> Again, once you cross a certain scale threshold, signing/deployment is 
> so automated that the leaf key could change at any time, leaving your 
> service in the dark about new keys. You could automatically add new 
> trusted keys to the service but it depends on the service environment 
> and how much you want to automate what the service trusts.
> 
> So what does measuring the keyring do? It allows you to put long-lived 
> trusted CAs in .builtin_trusted_keys. On the service if you trust the CA 
> and you trust the running kernel to do the right thing during key 
> enrollment, you can trust that loaded files are properly signed.

This is my gap in understanding.

Even if I somewhat trust the keys on the built-in keyring, I may not 
trust every key on the IMA keyring.

I may trust the kernel that ran at the time the key was enrolled, but I 
don't trust the one that's currently running until I attest.  Or, are 
all the keys on both keyrings erased before any kernel SW update?  I 
don't think so.

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Jordan Hand]

On 6/18/19 10:31 AM, Ken Goldman wrote:
> On 6/10/2019 12:57 PM, Jordan Hand wrote:
>>
>> Thought I'd jump in this conversation to see if I can clarify what I 
>> see as the value of this patch set.
>>
>> At a certain point, keeping a list of all known-good (or known-bad) 
>> hashes becomes infeasible. We could probably disagree about at what 
>> scale this happens but I think we could agree that eventually this 
>> happens (let me know if you still disagree with this assertion). So at 
>> this point you likely need to rely on a few things:
> 
> I've seen large systems with 60,000 measurements.  Even if that goes to 
> 100,000, *10 for bad measurements, and *10 for future expansion, that's 
> only 10M, or 320 mbytes.  That's pennies of disk space.

Ah, so I'm not really worried about disk space/file size. I'm worried 
about the need to update the service every time a new key is used to 
sign something.

Lets say the people who are maintaining the attestation service (Team A) 
are different from the people writing/signing the code to run on the 
client (Team B). The problem is that Team A has to take an update 
whenever a new signing key is used. And rolling leaf keys is often an 
automatic process so Team B may not even know exactly when a new leaf 
key is used. They just know its the same CA. And now as Team A, I may 
trust code as long as its signed by 1 of 10 different sources.

My concern is more that the process of keeping track of these leaf keys 
doesn't scale. This is where having a shared/static CA shines (as it 
does in other PKI infrastructures like TLS).

> 
>>
>> (1) is the file >= <known good version>. This allows you to forbid any 
>> kernel version before a vulnerability was fixed.
> 
> Perhaps, but one might also exclude a newer version, either because of a 
> regression, a certification, etc.
> 
>>
>> (2) Was it signed with a good, trusted, production key.
>>
>> You can sort of do this today by using the keyid. The issues with this 
>> are (a) collision (though the chance may be pretty remote. I don't 
>> have the crypto expertise to make an empirical call on that) and (b) 
>> you need to know all the possible signing keys in the service.
> 
> The 4 byte key id was probably a long term mistake, but can be fixed. 
> Today, a collision is remote.  Even then, just try both keys.  Nothing 
> breaks.
> 
>>
>> Again, once you cross a certain scale threshold, signing/deployment is 
>> so automated that the leaf key could change at any time, leaving your 
>> service in the dark about new keys. You could automatically add new 
>> trusted keys to the service but it depends on the service environment 
>> and how much you want to automate what the service trusts.
>>
>> So what does measuring the keyring do? It allows you to put long-lived 
>> trusted CAs in .builtin_trusted_keys. On the service if you trust the 
>> CA and you trust the running kernel to do the right thing during key 
>> enrollment, you can trust that loaded files are properly signed.
> 
> This is my gap in understanding.
> 
> Even if I somewhat trust the keys on the built-in keyring, I may not 
> trust every key on the IMA keyring.

Its a different policy than is maybe used today in IMA, but often it is 
the case that I want indirect trust. I (Party A) trust Party B. Party B 
trusts parties C, D, and E. And long as party B trusts them, then party 
A can also trust C, D, and E. It allows for a service to trust any code 
that chains to a CA, but not trust any code that doesn't, in cases where 
the service may not know the exact hashes or leaf keys it should trust.

> 
> I may trust the kernel that ran at the time the key was enrolled, but I 
> don't trust the one that's currently running until I attest.  Or, are 
> all the keys on both keyrings erased before any kernel SW update?  I 
> don't think so.

On a cold boot, the keys would be re-enrolled. I'm not sure about the 
kexec case. But as long as you carry-forward the measurement log across 
kexec, you can attest to the whole chain (this assumes TPM-based 
attestation).

And if you don't carry forward the measurements, there are some other 
server side things you can do to reconstruct the PCR state. But I think 
that's a bit out of scope for this discussion.

-Jordan

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Lakshmi]

On 6/18/19 10:52 AM, Jordan Hand wrote:

Hi Ken,

Did we (Jordan and I) address your concerns related to this patch set?

If you have more questions\concerns I'll be happy to respond.

Thanks,
  -lakshmi

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Lakshmi]

On 6/25/19 1:27 PM, Lakshmi wrote:
> On 6/18/19 10:52 AM, Jordan Hand wrote:
> 
> Hi Ken,
> 
> Did we (Jordan and I) address your concerns related to this patch set?
> 
> If you have more questions\concerns I'll be happy to respond.
> 
> Thanks,
>   -lakshmi

Hi Ken\Mimi,

I wanted to check again - Did Jordan and I address your concerns?
Do you have more questions\concerns related to this patch set?

Please let me know.

Thanks,
  -lakshmi

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Mimi Zohar]

On Tue, 2019-07-16 at 09:33 -0700, Lakshmi wrote:
> Hi Ken\Mimi,
> 
> I wanted to check again - Did Jordan and I address your concerns?
> Do you have more questions\concerns related to this patch set?
> 
> Please let me know.

I made my thoughts on this subject pretty clear.

Mimi

Re: [PATCH 0/2] [IMA] Measure public keys of BuiltIn Trusted Keys

[Lakshmi]

On 7/16/19 10:51 AM, Mimi Zohar wrote:

> On Tue, 2019-07-16 at 09:33 -0700, Lakshmi wrote:
>> Hi Ken\Mimi,
>>
>> I wanted to check again - Did Jordan and I address your concerns?
>> Do you have more questions\concerns related to this patch set?
>>
>> Please let me know.
> 
> I made my thoughts on this subject pretty clear.
> 
> Mimi
> 

Thanks Mimi.

  -lakshmi