From mboxrd@z Thu Jan 1 00:00:00 1970 From: mjg59@google.com (Matthew Garrett) Date: Wed, 04 Apr 2018 01:13:10 +0000 Subject: [GIT PULL] Kernel lockdown for secure boot In-Reply-To: References: <4136.1522452584@warthog.procyon.org.uk> <186aeb7e-1225-4bb8-3ff5-863a1cde86de@kernel.org> <30459.1522739219@warthog.procyon.org.uk> <9758.1522775763@warthog.procyon.org.uk> <13189.1522784944@warthog.procyon.org.uk> <9349.1522794769@warthog.procyon.org.uk> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, Apr 3, 2018 at 5:56 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett wrote: > > > > The generic distros have been shipping this policy for the past 5 years. > .. so apparently it doesn't actually break things? Why not enable it > by default then? Because it does break things, and the documented fix is "Disable Secure Boot by running mokutil --disable-validation". > And if "turn off secure boot" really is the accepted - and actuially > used - workaround for the breakage, then > WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST > PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED? > Sorry for shouting, but really. We have a thread of just *how* many > email messages that asked for the explanation for this? All we got was > incomprehensible and illogical crap explanations. There are four cases: Verified Boot off, lockdown off: Status quo in distro and mainline kernels Verified Boot off, lockdown on: Perception of security improvement that's trivially circumvented (and so bad) Verified Boot on, lockdown off: Perception of security improvement that's trivially circumvented (and so bad), status quo in mainline kernels Verified Boot on, lockdown on: Security improvement, status quo in distro kernels Of these four options, only two make sense. The most common implementation of Verified Boot on x86 platforms is UEFI Secure Boot, so this patchset includes an option that (if set) results in the kernel doing the right thing without user intervention. This makes it easy for a user to switch between the two states that make sense by running a single command and then following some prompts on the next reboot. The alternative would be to provide a signed kernel that always enabled lockdown and an unsigned kernel that didn't, which would (a) increase load on distributions and (b) force users to both run mokutil --disable-validation and also install a different kernel. I'm sorry if I've appeared tetchy in this discussion - having several of my coworkers shot has not done wonders for my mood. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html