On Mon, Jun 17, 2019 at 10:05 AM Ken Goldman <kgold@xxxxxxxxxxxxx> wrote: > On 6/7/2019 1:15 PM, Lakshmi wrote: > > 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. If you can assert that all code you've signed with your Secure Boot signing key is trusted, and that all keys that are embedded within code that's signed with your Secure Boot signing key are trusted, and that all keys signed with those keys are trusted, then you just need a mechanism to measure each component of that chain and attest to it. This is, as an example, the default Bitlocker policy under Windows - rather than seal the disk encryption secret to the full set of PCR values, the secret is sealed to PCR7. If a non-Windows bootloader is inserted into the boot process the PCR7 measurement will change (due to it being signed with a different certificate) and the unsealing will fail. Since Microsoft can assert that they will never sign something that they don't trust, this avoids having to re-seal the secret every time they update the bootloader. > 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. If you want to construct more complex policies then you need to examine more information :) This approach doesn't work for your case, but if the policy concern is "I want to ensure that all code run on this system came through my build pipeline" then you don't need to look at individual signatures.
