On 6/5/2019 8:16 PM, Lakshmi wrote:
The motive behind this patch series is to measure the public key
of keys in BuiltIn_Trusted_Keys keyring to IMA log.
I don't understand the motivation behind this proposal. Below, you
explain what you do. Can you explain why?
I.e., I don't see a problem with the proposal, but what is the benefit?
The kernel could be built with the config parameter
CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY enabled.
If this is done only those "IMA Signer Keys" that are signed by a key in
the "BuiltIn Trusted Keys" or the "Secondary Trusted Keys" can be added
to the "IMA Keyring".
In other words, "IMA Signer Keys" are attested by the "Trusted Keys"
on the client machines if the above config parameter is enabled.
IMA will enumerate the keys in the Trusted Keys keyring, and measure
them in the IMA log. On file read, IMA will validate the signature of
the system files using "IMA Signer Key" present in "IMA Keyring".
An attestation service would receive the "Trusted Keys" from
a trusted source (which is different from the client machines it is
attesting). The service would compare the Trusted Keys reported by
the client with the list of known Trusted Keys. A client would be
marked trusted by the service if and only if the keys reported
by the client are all trusted.
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?
Using the above approach the attestation service will be attesting
the "IMA Signer" while the clients attest the IMA Signature of
the system files. This enables the service to attest the client
machines by maintaining only a list of "Trusted Keys". These keys
change much less frequently than "IMA Signer Keys". It also frees
the service from having to maintain the "Hash of System Files"
which would change very frequently. This approach would significantly
reduce the maintenance cost of the service with respect to the data used
for attesting clients.
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.
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.
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?
