F20 System Wide Change: Enable kdump on secureboot machines

[Miloslav Trmač]

On Thu, Jul 11, 2013 at 1:40 PM, Jaroslav Reznik <jreznik at redhat.com> wrote:
> = Proposed System Wide Change: Enable kdump on secureboot machines =
> https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot

> == Detailed description ==
> /sbin/kexec prepares a binary blob, called purgatory. This code runs at
> priviliged level between kernel transition. With secureboot enabled, no
> unsigned code should run at privilige level 0, hence kexec/kdump is currently
> disabled if secureboot is enabled.
>
> One proposed way to solve the problem is that sign /sbin/kexec utility. And
> upon successful signature verification, allow it to load kernel, initramfs, and
> binary blob. /sbin/kexec will verify signatures of kernel being loaded before
> it asks running kernel to load it.

For someone like me unfamiliar with kdump architecture, wouldn't it be
possible to generate all relevant blobs (kdump kernel/initrd, ...) at
kernel build time and sign them using essentially the existing module
signing mechanism, and let the _kernel_ do all signature verification?
 Then /sbin/kexec wouldn't have to be trusted at all.

> === Build and ship ima-evm-utils package ===
> /sbin/kexec will be signed by evmctl. This utility will put an xattr
> security.ima on /sbin/kexec file and kernel will leverage IMA infrastructure in
> kernel to verify signature of /sbin/kexec upon execution.

(My motivation for the above question is that I view IMA (and any
approach based on verifying only a pre-specified subset of files) as
rather suspect, and that dm-verity makes much more sense to me for
enforcing a "trusted base OS".  This doesn't automatically mean that
kdump shouldn't be using IMA, however I fear that once we start for
one binary, calls to verify more of userspace using IMA will be
difficult to resist.)
    Mirek