[PULL REQUEST] Kernel lockdown patches for 5.2

[Mimi Zohar]

On Mon, 2019-03-11 at 17:42 -0700, Matthew Garrett wrote:
> On Wed, Mar 6, 2019 at 8:24 PM Matthew Garrett <mjg59 at google.com> wrote:
> >
> > On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar <zohar at 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