On Mon, 2019-03-11 at 17:42 -0700, Matthew Garrett wrote: > On Wed, Mar 6, 2019 at 8:24 PM Matthew Garrett <[email protected]> wrote: > > > > On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar <[email protected]> wrote: > > > 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)?
There's a slight nuance you're missing. If the arch policy is enabled and the kernel supports module signatures, do not add an IMA appraise rule. A custom policy could require an IMA signature, as well as the module appended signature. Saying only use the module signatures, even if the IMA custom policy contains a kernel module rule, doesn't make sense. > If so, that just leaves kexec. For platforms that support > PE signing for kernels (x86 and arm), are we ok punting to that? Similarly, if the custom policy has a kexec kernel image policy rule, it shouldn't be ignored. > 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 The kernel image could be signed with an appended signature as well. > 2) CONFIG_INTEGRITY_TRUSTED_KEYRING is set in order to prevent an > attacker being able to add a key to the keyring Agreed > Does this sound reasonable? Are there any further criteria that are > required for this? With the caveats described above. Mimi
