Re: [PATCH 00/16] [RFC PATCH] Signed kexec support

[Vivek Goyal <vgoyal@redhat.com>]

On Wed, Sep 11, 2013 at 08:40:23PM -0700, Greg KH wrote:
> On Tue, Sep 10, 2013 at 05:44:15PM -0400, Vivek Goyal wrote:
> > Hi,
> > 
> > Matthew has been posting patches to lock down kernel either due to
> > secureboot requirements or because of signed modules with signing
> > enforced. In kernel lock down mode, kexec will be disabled and that
> > means kdump will not work either.
> > 
> > These patches sign /sbin/kexec and kernel verifies the signature
> > and allows loading a kernel if signature verification is successful.
> > IOW, trust is extended to validly signed user space.
> > 
> > Currently it works only for statically linked applications.
> 
> That's a really big restriction, pretty much making it not workable for
> distros at the moment to use.

It is a big restriction for general use case of signed user space but in
this case I am planning to build /sbin/kexec statically and solve the
kexec/kdump issue.

I have posted kexec-tools patches here.

https://lists.fedoraproject.org/pipermail/kernel/2013-September/004469.html

Once kernel patches get in, I plan to upstream kexec-tools patches too
and then distros should be able to build /sbin/kexec statically and
this should work.

Do you forsee a problem with that?

> 
> Any chance to change this in the future?

It might but currently I don't have any plans. I see atleast two issues
with that.

- If we allow dynamic linking for signed binaries, then dynamic libraries
  will have to be signed too. I suspect in that case pretty much whole of
  the user space will have to be signed. I am not sure if distros are
  willing to do that.

- Currently a shared library can be written on disk (unlike executables)
  while it is mapped. That means after signature verification a root just
  has to open and write to shared library and modify code and defeat the
  purpose of signature verfication.

Probably these issues can be addressed if there is a need. Just that I
have not looked into it.

> Or just rely on the existing
> "signed binaries" functionality we have in the kernel today for the
> kexec binary as well?  Wouldn't that be simpler?

Which signed binary mechanism are you referring to? Are you referring to
using IMA for signature verification? If yes, there are some issues with
that.

- IMA does not lock down signed binaries in memory. That means after
  signature verification files can potentially be swapped out and be
  attacked there and modified code then can be swapped back in.

- IMA caches the signature appraisal resutls and reappraises the things
  based on if file has been modified or not. But this does not detect any
  raw writes to disk. So after signature verification root should be able
  to do some raw writes to disk and IMA will think file signature are
  just fine.

- IMA does not have mechanism to keep track of signed applications and
  a mechanism to disallow ptrace() by unsigned applications. That means
  after signature verification root can just ptrace() signed binary and
  modify its code/data.

- IMA provides mechanism for file based signature verificaiton.
  kexec-tools also needs to verify signature of new kernel being loaded.
  Using IMA on bzImage file has same pitfalls where a file can be modified
  after signature verification.

  That's why I have extended keyctl() so that signature verification can
  be done on user space buffer. An application can first read a file in
  buffer and then ask kernel to verify signature. And now root should not
  be able to attack it.

So existing IMA does not seem to have been written for an environment
where all the user space is not signed we don't trust root and root can
attack a signed binary. And my patches try to fill that gap. 

Thanks
Vivek