F20 System Wide Change: Enable kdump on secureboot machines

[Vivek Goyal]

On Thu, Jul 11, 2013 at 05:19:58PM +0200, Florian Weimer wrote:
> On 07/11/2013 04:33 PM, Vivek Goyal wrote:
> 
> >>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.
> 
> The IMA stuff looks pretty independent of Secure Boot to me.  It
> seems upstream picked up some of it in 2.6.30.
> 

It is but it implements stuff which is needed to meet TCB requirements.
Current implementation is nowhere near to require secureboot requirements.

For example, executables are not locked down in memory. That means
after signature verification, if executable gets swapped out, it can
be tweaked by root.

Any direct changes to disk to a file are not detected. So modify
the disk blocks after signature verification and IMA will not
notice it.

Without secureboot we don't have any requirement where we need
the capability to extend root of trust to user space application. Current
IMA is not sufficient to meet secureboot requirements. So pushing
more patches in because they are required to meet secureboot
requirements is hard. (Because lot of people don't bite into the
theory of locking down kernel in secureboot mode).

So there is very little direct dependecny on secureboot. It is
more of why do you need these enahancements. And answer is because
secureboot will enforce that. Well, secureboot locking is not
even in kernel, and kdump is not even broken upstream, so why
are you bothering to push something in now.


> >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.
> 
> The important question is whether we can drop our own patches and
> switch to whatever upstream does when the time comes.

I think we should be able to do that. We are expecting only /sbin/kexec
to use this functionality and if things change we can change /sbin/kexec
and signing process as we control everything.

I think important thing will be to emphasize that other applications
should not try to latch on to new keyctl() ioctl option to verify 
signature of a user space buffer or IMA functionality to put extra
data in signature which locks down executable in memory. These
are not stable interfaces and might disappear in next fedora
release.

> 
> >I think now we can not back out. Merging secureboot patches without
> >these being upstream broke other subsystems (kdump, systemtap,..).
> 
> Sure.  But systemtap (and things like PCI passthrough) are
> fundamentally incompatible with our approach to Secure Boot.  There
> are conceptual challenges like irreversible software updates, too.
> At a certain point, we will have added so much inconvenience that
> only very few users will use this feature.  Upstream is not totally
> crazy in rejecting Fedora's restrictive approach.
> 

Is it time to re-visit the decision of locking down kernel on secureboot
machine given the fact that upstream does not seem to like the idea.

What are other distributions planning to do? Are they carrying additional
patches or they have decided to go upstream way of not locking down
kernel.

If others are going upstream way, then is it worth that fedora continues
to be different and in the process we continue to add more out of the
tree patches to make things like kdump work with secureboot.

> The proposed change goes in the right direction (more user control),
> but we're still missing things on the restrictive side (dbx updates,
> Fedora-local revocation checking, and others I'm not aware of).  And
> as long as Fedora and the more lenient distributions are under the
> same trust root, Fedora users get pretty close to zero additional
> security benefit, despite all the effort we put into this.
> 
> >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.
> 
> Okay, that's a dependency on the Secure Boot patchset, but not
> Secure Boot as a technology.  Good to know.
> 
> >I have not written the code to check blacklist yet but I plan to do
> >that later.
> 
> There's a challenge to obtain the blacklist in a way that is safe
> against rollback.
> 
> I don't think we have indirect (and proven) write access to the dbx
> variable yet.

Ok, I am not aware of details here but if blacklisting does not work
already, then this concern is not specific to kdump. Once it starts
working and I can blacklisted keys in blacklist keyring, I should be
able to check for key in that keyring and disallow sys_kexec().

> 
> >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.
> 
> Then you better add a separate CA root for /sbin/kexec, so that we
> don't have to blacklist the kernel.  (An alternative would be to
> blacklist binaries based on their hashes.)

To keep things simple, I was thinking if we use same CA root which
we use for signing kernel, it will become easier and I don't have
to start a new CA root only for /sbin/kexec.

Downside is that if CA root used for signing kernel ever gets
compromised, then we will have to issue kexec-tools update too (in
addition to shim, kernel, grub). I guess issuing kexec-tools update
is simpler.

> 
> Revocation as the result of a software bug seems far more likely to
> me than revocation because of CA compromise (although I don't know
> what Fedora does with these keys, but at least this is a something
> that's solvable in principle with suitable hardware and processes).
> 
> >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?
> 
> Not sure I follow.  You can't add additional root (that is, CA) keys
> after building.  What you could do is add intermediate CAs, but the
> way X.509 works, this is unnecessary if you put the entire chain
> (perhaps excluding the root) into the binary.  So this shouldn't be
> required at all.

I was hoping that CA certificate will be embedded in kernel at build
time. And using that CA certificate we will sign keys which in turn
will sign /sbin/kexec. And that key will be loaded dynamically at
boot time in system_keyring. (And it should be allowed because CA key
is already there and it can verify the new key being loaded).

IIUC, PKCS7 signatures can carry all the signign chain info and 
hence intermediate certifiates don't have to be loaded separately.

Like modules, /sbin/kexec will not use PKCS7 format. So it only knows
about the key it has been signed with and expects that key to be
loaded already. 

Did I understand your question correctly?

Thanks
Vivek