On Thu, Jul 11, 2013 at 1:40 PM, Jaroslav Reznik jreznik@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