On Mon, 2018-03-12 at 19:30 -0400, Mimi Zohar wrote: > On Mon, 2018-03-12 at 15:30 -0700, James Bottomley wrote: > > > > On Mon, 2018-03-12 at 17:53 -0400, Mimi Zohar wrote: > [...] > > > > > > > > - This use case, when the TPM is not builtin and unavailable > > > before > > > IMA is initialized. > > > > > > I would classify this use case as an IMA testing/debugging > > > environment, when it cannot, for whatever reason, be builtin the > > > kernel or initialized before IMA. > > > > > > From Dave Safford: > > > For the TCG chain of trust to have any meaning, all files > > > have to > > > be measured and extended into the TPM before they are > > > accessed. > > > If > > > the TPM driver is loaded after any unmeasured file, the chain > > > is > > > broken, and IMA is useless for any use case or any threat > > > model. > > > > I don't think this is quite the correct characterisation. In > > principle the kernel could also touch the files before IMA is > > loaded. However, we know from the way the kernel operates that it > > doesn't. We basically trust that the kernel measurement tells us > > this. The same thing can be made to apply to the initrd. > > With the builtin "tcb" policy, IMA-measurement is enabled from the > very beginning. Afterwards, the system can transition to a custom > policy based on finer grain LSM labels, which aren't available on > boot. > > > > > The key question is not whether the component could theoretically > > access the files but whether it actually does so. > > As much as you might think you know what is included in the > initramfs, IMA-measurement is your safety net, including everything > accessed in the TCB. The initrd *is* part of the Trusted Computing Base because it's part of the boot custody chain. That's really my point. If I don't know what's in my initrd, I've broken the chain there and IMA can't fix it. James
