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

[Lakshmi <nramas@linux.microsoft.com>]

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