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.