On 8/30/19 11:41 AM, Mimi Zohar wrote:
No, the measurement list ima-sig template record contains both the
file hash and signature. There's no need to maintain a white list of
either the file hashes or signed hashes. All that is needed is the
set of permitted public keys (eg. keys on the trusted IMA keyring).
You are right - Thanks for the info.
Even though on the local system, files signed by the system owner
would be permitted, the attestation server would be able to control
access to whatever service. For example, Trusted Network Connect
(TNC) could control network access. By measuring the keys on the
builtin/secondary keyrings, that control is not based on who signed
the software package, but based on who signed the certificate of the
key that signed the software package. My concern is how this level of
indirection could be abused.
Since the signer of certificate of the key that signed the software
package changes much less frequently compared to the certificate of the
key used to sign the software package, the operational overhead on the
server side is significantly reduced.
I understand there is another level of indirection here. But I am also
not clear how this can be abused.
All of this would still be true, if you measured the keys on the
trusted IMA keyring, but without the level of indirection described
above. Depending on your use case scenario, the problem with this
approach is maintaining a list of all the certificates that have been
signed by keys on the builtin, and if enabled, the secondary keyrings.
Yes - that is the issue we are trying to avoid. Especially since the
list of signing certificates can grow faster than the signer of those
certificates (that are present in the builtin/secondary keyrings)
In the last LSS-NA BoF, Monty suggested, for a different use case, one
that needs to seal keys, measuring keys and extending a separate PCR.
Thanks for the info. I will gather more information on this one.
-lakshmi
