F20 System Wide Change: Enable kdump on secureboot machines

[Vivek Goyal]

On Thu, Jul 11, 2013 at 03:57:38PM +0200, Florian Weimer wrote:
> On 07/11/2013 01:40 PM, Jaroslav Reznik wrote:
> >=== 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.
> 
> Is there a chance this (and the other patches mentioned below)
> actually makes it in the kernel?  Are at least the VM changes part
> of upstream already?
> 
> I don't think it would make sense to add more and more
> Fedora-specific patches which implement security functionality.  I
> don't want Fedora to become the next Android.

I don't see those patches going upstream in near term. First of all
base secureboot patches need to go upstream. And at this point of
time upsteram does not seem to be eager to do anything more in kernel
for secureboot.

Secondly, there are disagreements upstream w.r.t how locking down
executable should happen. IMA folks want some functionality behind
security hooks (as opposed to what I have done). So I am expecting
that once patches do get merged upstream, they might be in little
different shape altogether.

I think now we can not back out. Merging secureboot patches without
these being upstream broke other subsystems (kdump, systemtap,..). And
we should now allow other non-upstream patches to go in to make 
these subsystems work again. Or we should remove kernel lockdown
functionality in secureboot mode altogether (as upstream does not
have it).

> 
> >=== 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.
> 
> Does this mean your implementation of signature checking will be
> completely independent of UEFI Secure Boot (unless you decide to use
> that to obtain the trust root)?

Yes. I am going to use IMA for signature verification. These signatures
formats are very close to what is used for module signing (PKCS1.5 with
some metadata).

For trust chain, we will still use secureboot trust chain and trust
an executable only if it has been signed by a key in .system_keyring.

> 
> >=== 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.
> 
> How do you intend to handle revocation?

I have not written the code to check blacklist yet but I plan to do 
that later.

If a key is revoked, I am expecting that we will request M$ for an 
update. And also push out new version of /sbin/kexec signed with
a new key. 

We will need to have this new key signed with either redhat certificate
or signed with M$ so that it can be loaded in already running kernel. That
will make sure old /sbin/kexec instances don't run while new instances
signed with new key do run.

> 
> >* 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.
> 
> Who is the appropriate authority?

I am not sure yet. I was thinking that can we embed fedora/redhat
certificate in kernel (like shim) and use that as CA key to sign
/sbin/kexec key.

Signing a key using CA key will require loading of that key every
reboot automatically. I am not sure how that can be handled. May 
be rpm packages can drop those keys in some directory and a system
service scans for keys and loads these every reboot?

Thanks
Vivek