On Tue, May 1, 2018 at 4:43 PM Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2018-05-01 at 22:32 +0000, Matthew Garrett wrote: > > INTEGRITY_KEYRING_MODULE is defined, but doesn't appear to be used > > anywhere. Odd. Anyway, distributions are unlikely to ship with > > CONFIG_INTEGRITY_TRUSTED_KEYRING since it makes it impossible for users to > > determine which set of IMA or EVM signatures they want to trust. So if > > validation is against the IMA keyring rather than builtin_trusted_keys, > > it's going to be possible for users to extend the set of trusted keys. If > > CONFIG_KEXEC_BZIMAGE_VERIFY_SIG is set then the kernel seems to do the > > right thing here, but it's not clear to me how that's supposed to interact > > with IMA? > From your description, whatever keys the distros are loading onto the > builtin_trusted_keys keyring for verifying the kexec kernel image, > could just as easily be added to the IMA trusted keyring > (CONFIG_INTEGRITY_TRUSTED_KEYRING). I don't see the difference. If CONFIG_INTEGRITY_TRUSTED_KEYRING isn't set then you can load new (and unsigned) IMA keys from userspace. So if IMA is the lockdown control mechanism for kexec, distros must either set CONFIG_INTEGRITY_TRUSTED_KEYRING (which I don't think is practical) or IMA should test kexec against the builtin_trusted_keys keyring rather than the IMA keyring. Or have I misunderstood how this works?
