- Release Signoff Checklist
- Summary
- Motivation
- Proposal
- Design Details
- Drawbacks
- Alternatives
- Infrastructure Needed (optional)
- Enhancement issue in release milestone, which links to pull request in [keylime/enhancements]
- Core members have approved the issue with the label
implementable - Design details are appropriately documented
- Test plan is in place
- User-facing documentation has been created in [keylime/keylime-docs]
IMA's policy implements support for policy rules that cause keys loaded onto kernel keyrings to be logged in the IMA measurement log in 'ima-buf' entries. This now provides the opportunity to also learn the keys that IMA is using for signature verification from these 'ima-buf' entries, where the DER-encoded public key is reported as part of the measurement log entry. The learned keys can then be used to verify the subsequent signatures found in the log.
Recent extensions to Keylime's allowlist (policy) enable Keylime to verify 'ima-buf' entries similar to verifying file entries and their allowed hashes. If IMA is now reporting keys loaded onto keyrings then the allowlist must have the corresponding entries for the keyrings, otherwise the system will fail log verification. Having these entries in the allowlist implies that the system administrator agrees to the list of keys being loaded and therefore Keylime can also learn which keys are used by a given system for signature verification and also use those keys from the measurement log to verify the signatures itself rather than the administrator having to provide the keys.
The goal of this enhancement is to make the management of IMA signature verification keys easier. Since a system administrator has to provide allowed keys' hashes in the allowlist already he should not have to provide the IMA signature verification keys for Keylime to be able to verify file signatures.
Based on data from the 'ima-buf' log entries where IMA reports keys loaded onto a system's keyrings, Keylime will learn which keyrings are in use on a system and can then model those keyrings and the keys associated with them. It can then use those keys for signature verification.
The modeled keys and keyrings will be persisted in the database to support incremental attestation.
A system administrator using an IMA policy rule like the following does not need to manage a system's IMA signature verification keys anymore since Keylime will learn about the existence of the .ima keyring and the keys loaded onto it.
measure func=KEY_CHECK keyrings=.ima
The Keyime database will need to be extended with a column for storing the keyrings and keys learned from the IMA log. Every time a system is attestated to starting with log entry 0 the previously learned keyring and keys are discarded since the IMA log is expected to again report the keyrings and keys.
The keylime database will be upgradable and downgradable with an SQL Alchemy script.
No new dependencies will be introduced.
None known.
If a system administrator does not provide this type of an IMA policy rule then he/she will have to provide the IMA signature verification keys as before.