On 07/11/2013 06:03 PM, Vivek Goyal wrote:
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.
Ah, okay, so for Trusted Boot, the onus is on the system administrator
to make sure that he can provide attestation (by not running any dodgy
binaries which would invalidate that), but for Security Boot, we have to
prevent the system administrator to run such binaries. Makes sense.
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.
Okay.
There some potential ABI impact from the VM-related changes, but this
shouldn't be a problem for Fedora.
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.
I think they don't do any lockdown after boot. CAP_COMPROMISE_KERNEL
(or what's it called these days) is a Fedora thing.
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().
There are some potential approaches to blacklisting which would be
incompatible with certain ways of signing binaries. So it's not
immediately clear if an unrelated blacklisting service could be made to
work with userspace signatures.
So let's skip the blacklisting discussion for now. If we ever have to
implement it, it's going to be messy, kexec or no kexec. (See the
discussion about post-release media respins.)
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.
Ah, okay, that's an unfortunate upstream design decision. In this
light, what you're planning to do seems fairly unavoidable.
Have you considered a non-cryptographic solution, like a physical
presence check to (temporarily) disable Secure Boot so that the kexec
restriction no longer applies? This could be a fallback option if the
original plan turns out to be too brittle/complex.
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
