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.
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 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.
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.
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.)
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.
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
