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
