On Thu, 2019-02-28 at 19:33 -0800, Matthew Garrett wrote:

On Thu, Feb 28, 2019 at 5:45 PM Mimi Zohar [off-list ref] wrote:

quoted

On Thu, 2019-02-28 at 17:01 -0800, Matthew Garrett wrote:

quoted

quoted

That's not a valid reason for preventing systems that do use IMA for
verifying the kexec kernel image signature or kernel module signatures
from enabling "lock down".  This just means that there needs to be
some coordination between the different signature verification
methods. [1][2]

I agree, but the current form of the integration makes it impossible
for anyone using an IMA-enabled kernel (but not using IMA) to do
anything unless they have IMA signatures. It's a problem we need to
solve, I just don't think it's a problem we need to solve before
merging the patchset.

That's simply not true.  Have you even looked at the IMA architecture
patches?

Sorry, I think we're talking at cross purposes - I was referring to
your patch "ima: require secure_boot rules in lockdown mode"
(https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=efi-lock-down&id=7fa3734bd31a4b3fe71358fcba8d4878e5005b7f).

With the "secure_boot" rules it was difficult to coordinate the
different signature verification methods.  Plus they weren't
persistent after loading a custom policy.

If the goal is just to use the architecture rules then I don't see any
conflict, 

yes

and as far as I can tell things would just work as is if I
drop the ima portion from "kexec_file: Restrict at runtime if the
kernel is locked down"?

That code is a remnant left over from when the "secure_boot" policy
was enabled.  However, dropping the IMA portion there would result in
allowing only PE signed kernel images.  (On Power, for example, there
aren't any PE signatures.)

My suggestion would be to drop this patch and require the architecture
specific policy in "lock down" mode.

 Apologies, I'd thought that the secure_boot
ruleset was still intended to be used in a lockdown environment.

No, not any longer.

Mimi