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.
