On Tue, Apr 3, 2018 at 6:43 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Apr 3, 2018 at 6:13 PM, Matthew Garrett <mjg59@xxxxxxxxxx> wrote: > > > > There are four cases: > No. > Matthew., stop with the agenda already. > This shit is what I'm talking about: > > Verified Boot off, lockdown on: Perception of security improvement that's > > trivially circumvented (and so bad) > You're doing some serious value judgement that is simply bogus. > If lockdown actually helps avoid CPL0 execution attacks, then it helps > even if secure more is off. Bear in mind that I'm talking about defaults here - in more constrained configurations the answers may change. But the kernel has no way of knowing whether it's in one of those configurations, and as a result there's an argument for not overpromising on the security that you're providing users. If a user has a configuration where you're able to verify that userspace has some degree of protection (eg, disk encryption keys are in the TPM and won't unseal if someone's switched out the kernel) then it's reasonable for userland (or a kernel command line option) to enable the functionality. What I'm afraid of is this turning into a "security" feature that ends up being circumvented in most scenarios where it's currently deployed - eg, module signatures are mostly worthless in the non-lockdown case because you can just grab the sig_enforce symbol address and then kexec a preamble that flips it back to N regardless of the kernel config. This is the sort of thing that's not obvious to most users, and it potentially causes them to make worse security decisions as a result. The goal for this part of the patchset isn't to cover every single conceivable case, it's to provide reasonable defaults in a way that makes life easier for distributions. > Or think of virtual machines - which people often use on purpose for > security things. Again, they very much are _not_ going to have secure > boot, but it's not necessarily even possible to "replace the kernel > and reboot" at all, because the kernel came from outside the virtual > machine entirely, and rebooting might just kill the VM rather than > restart anything. And where you have a trustworthy external thing providing your kernel, yeah, that's also an argument - and having a kernel command line argument that enables it in this case also seems entirely reasonable. > This is what I mean by having an agenda. We all know you are a big > proponent of secure boot. But it seems to cloud your arguments, by > turning your assumptions and your agenda into an "argument" that is > simply not even TRUE. I'm making this argument from the perspective of "What should the kernel do when it has no additional information". Having the kernel automatically enable lockdown without the user being aware of which guarantees their environment is providing risks giving users the impression of security that they may not have - in that case it makes more sense to have the user make an explicit decision to enable it. > See what I'm unhappy about? > > Verified Boot on, lockdown off: Perception of security improvement that's > > trivially circumvented (and so bad), status quo in mainline kernels > I think this is entirely false too. Again, the "trivial circumvention" > shows a bias and agenda that isn't really all that true. > > Of these four options, only two make sense. > No. > You say that, because you have that bias and that agenda. Ok. Only two make sense *in the absence of additional information about local configuration*. Distributions have to make reasonable choices here, and where a configuration choice decreases functionality and provides what may only be a marginal increase in security it's not a good configuration choice to make by default. > That said, wouldn't it be equally good to just make the whole thing be > a protected EFI variable instead? Once you have physical access to the > EFI shell (to turn off secure boot) you have access to that too. That's pretty much exactly what mokutil does, without you needing to find a copy of the UEFI shell to install first. If you think there's a strong enough need for it, we could definitely add an additional variable that allowed you to disable lockdown without disabling signature validation. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
