On Wed, Mar 6, 2019 at 8:24 PM Matthew Garrett [off-list ref] wrote:

On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar [off-list ref] wrote:

quoted

The kexec and kernel modules patches in this patch set continues to
ignore IMA.  This patch set should up front either provide an
alternative solution to coordinate the different signature
verification methods or rely on the architecture specific policy for
that coordination.

Hi Mimi,

I'm working on a patch for this at the moment which can then be added
to either patchset. Is there a tree that contains the proposed Power
architecture policy? I want to make sure I don't accidentally end up
depending on anything x86.

I've been digging into this some more, and want to ensure that I get
the appropriate semantics. Are we happy with the x86 solution for
module signing (ie, if the arch policy is enabled and the kernel
supports module signatures, use module signatures rather than IMA
signatures)? If so, that just leaves kexec. For platforms that support
PE signing for kernels (x86 and arm), are we ok punting to that? If so
then to maintain the semantics we have for lockdown in general (ie, no
way for a user to modify ring 0 code) then I think that would mean
allowing kexec_file() only when the following criteria are met:

1) IMA is appraising kexec with digital signatures, either ima digital
signatures or ima hashes with associated EVM digital signatures
2) CONFIG_INTEGRITY_TRUSTED_KEYRING is set in order to prevent an
attacker being able to add a key to the keyring

Does this sound reasonable? Are there any further criteria that are
required for this?