F20 System Wide Change: Enable kdump on secureboot machines

[Jaroslav Reznik]

= Proposed System Wide Change: Enable kdump on secureboot machines =
https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot

Change owner(s): Vivek Goyal <vgoyal at redhat.com>

Currently kexec/kdump is disabled on machines with secureboot enabled. This 
feature aims to enable kexec/kdump on such machines.

== 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.

There are quite a few pieces to the puzzle. I am listing the some of the 
things which need to be done. 

=== 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. 

* There is a bz open 807476 for inclusion of this package since long time. Not 
sure what it is stuck on though. 

* There are some patches which are not upstream yet (like lock down executable 
in memory) which we need to carry in this patckage till patches get upstream. 

=== Changes to kexec-tools ===
Build /sbin/kexec statically. There is no infrastructure to sign and verify 
signature of shared libraries. Even if we can sign and verify shared 
libraries, currently kernel allows writing to shared libraries while these are 
mapped. So one can overwrite the library after signature verification. So build 
/sbin/kexec statically. kexec does not use nss related code, so there should 
not be any issues w.r.t glibc calling into other shared libraries. 

* Generate detached /sbin/kexec signautre at build time and install these 
signature on target in seucurity.ima xattr when kexec-tools is installed. 

* Modify kexec-tools so that it can call keyctl() and verify signature of a 
new kernel being loaded. 

=== Kernel Changes ===
Kernel needs to carry additional patches to do verify elf binary signature.
* There are patches to extend keyctl() so that user space can use it to verify 
signature of a user buffer (vmlinuz in this case).
* These patches are not upstream, so these need to be carried in fedora till 
patches get upstream.
* Kernel need to be signed using evmctl and detached signature need to be 
generated. These signatures need to be installed on vmlinuz upon kernel rpm 
installation in security.ima xattr. 

=== Signing Key Management ===
Yet to be figured out. There are couple of ideas on table.

* Embed few keys in kernel and one of these keys will be used to sign 
/sbin/kexec. In case of a key is revoked, use a new key from set of embedded 
keys.
* Ship a PE/COFF wrapped key in kexec-tools package. This PE/COFF binary 
should be signed by appropriate authority so it can be loaded in system 
keyring. 

== Scope ==
Proposal owners:
* Provide patches for kernel package.
* Provide patches for kexec-tools package.
* Provide patches for ima-evm-utils package.
* ima-evm-utils package will be new. It is not clear who will maintain that 
package. 

Other developers:
* Signing Process, Signing key management, Signing key loading on target after 
boot and Signature installation on target are unknown areas right now. It is 
not very clear how these things will be done. Once details have been figured 
out, it might require work from other developers. Not sure though at this 
point of time.
* Can't think any other major work required by other developers yet. We will 
have to figure out how signing will take place and how signatures will be 
installed on target system. And depending on how we do it, it might require 
some work from other developers. Like making use of rpm hooks to install 
signature etc. Given the fact that we are signing only one file /sbin/kexec, we 
might get away doing changes in kexec-tools spec file. 

Release engineering:
* We need to sort out how signing will take place. I will require release-
engineering help on this.
* For issues related to key management I will need help of security/release 
engineering. 

Policies and guidelines:
* I think to begin with we might not have to update any packaging guidelines 
for this. Anything magic w.r.t signing can probably be limited to kexec-tools 
spec file.