On Tue, 2018-05-01 at 23:46 +0000, Matthew Garrett wrote: > 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? Another option is enabling both CONFIG_INTEGRITY_TRUSTED_KEYRING and CONFIG_SYSTEM_EXTRA_CERTIFICATE. Mimi
