[Cc'ing David Howells, James Bottomley] On Thu, 2019-11-21 at 08:17 -0800, Lakshmi Ramasubramanian wrote: > Hi Mimi, > > >>> everything needed for verifying a signature is included in > >>> the key measurement. > > Regarding the requirement you had stated above, I would like some > clarification. > > When I started this change to measure keys through IMA, the use case we > had in mind was enabling an attestation service, for instance, to verify > if the client has only known good (trusted) keys - for example, in > keyrings such as ".builtin_trusted_keys", ".ima", etc. > > On the client IMA verifies the signature of system binaries using keys > in the IMA keyring. And, if the config namely > CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled, > only keys signed by a built-in trusted key can be added to the IMA keyring. > > An attestation service can keep a list of public keys of "known good > (trusted)" keys for various keyrings, and verify against the measurement > data provided by the client. Right, that's true, assuming the attestation server is aware of all possible public keys, which was the original reason you provided for measuring the keys on the builtin trusted keyring, not the IMA keyring. > > To achieve the above we decided to include only the public key in the > key measurement buffer. > > I would like to know what benefit we'd get by including "everything > needed for verifying a signature in the key measurement"? > > From testing point of view, if we have the certificate (like the .DER > file), we can validate the key measurement data in the IMA log. > > Do you see a need to include more data or the entire cert for the > product code? Your code has come a long way, since you first started. Please don't go back to what you originally intended/wanted to do. Measuring keys just on the builtin trusted keyring, as you did, was a non starter. It would never have been accepted upstream by me and doubtfully by David. The current measuring of keys is more generic and properly isolated to IMA. This is what I would have expected from the very beginning. Only now are the patches at the point, where there is something to even discuss. Now that you understand what patches should look like in order to be upstreamed, please look outside of your use-case scenario and think about the bigger picture. Remember changing the "key" measurement in the future would cause a userspace regression. So we need to fully understand what is needed, *before* it is upstreamed. Yes, changing what is measured might change the IMA hook placement. James Bottomley already started the discussion in this thread... Mimi
