Kdump with signed images

Vivek Goyal vgoyal at redhat.com
Fri Oct 26 13:06:09 EDT 2012

On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote:
> On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> > On a running system, the package installer, after verifying the package
> > integrity, would install each file with the associated 'security.ima'
> > extended attribute.  The 'security.evm' digital signature would be
> > installed with an HMAC, calculated using a system unique key. 
> The idea isn't to prevent /sbin/kexec from being modified after 
> installation - it's to prevent it from being possible to install a 
> system that has a modified /sbin/kexec. Leaving any part of this up to 
> the package installer means that it doesn't solve the problem we're 
> trying to solve here. It must be impossible for the kernel to launch any 
> /sbin/kexec that hasn't been signed by a trusted key that's been built 
> into the kernel, and it must be impossible for anything other than 
> /sbin/kexec to make the kexec system call.

I am kind of lost now so just trying to summarize whatever I have
learned so far from this thread.

- So say we can sign /sbin/kexec at build time and distros can do that.
- Verify the signature at exec time using kernel keyring and if
  verification happens successfully, say process gains extra capability.
- Use this new capability to determine whether kexec_load() will be
  successful or not.

Even if we can do all this, it still has the issue of being able to
stop the process in user space and replace the code at run time
and be able to launch unsigned kernel.

So until and unless we have a good solution to verify application's
integrity/authneticity at the time of kexec_load() system call we
still have the problem. And I don't think we have come up with a
solution for that yet (until and unless I missed something).

More information about the kexec mailing list