Messages in this thread | | | Subject | Re: [PULL REQUEST] Kernel lockdown patches for 5.2 | From | Mimi Zohar <> | Date | Mon, 11 Mar 2019 21:52:13 -0400 |
| |
On Mon, 2019-03-11 at 17:42 -0700, Matthew Garrett wrote: > On Wed, Mar 6, 2019 at 8:24 PM Matthew Garrett <mjg59@google.com> wrote: > > > > On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar <zohar@linux.ibm.com> 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
| |