Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Andy Lutomirski <luto@kernel.org>]

On Wed, Sep 5, 2018 at 1:34 PM, Justin Forbes <jmforbes@linuxtx.org> wrote:
> On Wed, Sep 5, 2018 at 3:14 PM, David Howells <dhowells@redhat.com> wrote:
>> Justin Forbes <jmforbes@linuxtx.org> wrote:
>>
>>> Lockdown is a config option on it's own, just also add a separate
>>> config option option to enable lockdown on UEFI secure boot.
>>
>> The patchset has that already (CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT).
>>
>> One of the issues appears to be that we're making it boot-time conditional at
>> all.  If I understand him correctly, Linus seems to want us to make everything
>> locked down at compile time or not at all.
>>
>
> The last push attempt dropped that patch and did have the compile time
> (CONFIG_LOCK_DOWN_MANDATORY) as well as an option for command line
> enabling with lockdown=1 (CONFIG_LOCK_DOWN_KERNEL).  It just didn't
> have an option for triggering off of UEFI Secure Boot.   As a distro,
> running   CONFIG_LOCK_DOWN_MANDATORY isn't much of an option. We ran
> the 4.17 development series in rawhide with CONFIG_LOCK_DOWN_KERNEL,
> and no one noticed that their secure boot was off.  This is why it is
> somewhat frightening to change the behavior, users assume it is all
> working because things boot, and never notice they are missing some
> protection that they assumed was there.  Before we rebased stable
> distros I reworked the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to work
> with the current patch set and that is what we are carrying now.
> While I would love to see everything pushed as a whole, I would still
> be much happier than I am now if everything else pushed and we only
> had to carry the patch to trigger off of UEFI status.  It is a minor
> detail that shouldn't be blocking the entire patch set at this point.
> If Linus agrees that it can be pushed with CONFIG_LOCK_DOWN_MANDATORY
> as the only option, that is fine. Still much less out of tree for us
> to worry about.

I'm not really convinced this needs a whole tech topic.  I send an
email awhile back, but didn't hear back, so here goes roughly again:

As far as I can tell, there are two issues blocking lockdown, both of
which should be relatively easily resolvable:

1. When exactly is lockdown enabled?

2. What exactly does lockdown do?

#1 is clearly resolvable.  Worst case, a bare minimum version can get
merged where, for example, lockdown is either mandatory or is enabled
by boot option.  Distros can carry a patch for alternative policies
for a little while until the dust settles.

#2 is a bigger deal.  At least one version that shipped in a Fedora
kernel actually broke systemd, and that's not cool.  And I really
think we need to make lockdown non-binary to get this right.  I've
proposed LOCKDOWN_PROTECT_INTEGRITY (i.e. try to prevent root from
modifying the running kernel) and LOCKDOWN_PROTECT_SECRECY (try to
prevent root from reading kernel memory), and no one seems to have
actually objected.

So I would propose the following.  Someone (me? David?) prepares a
very stripped down lockdown patchset.  It adds the basic config
options for CONFIG_LOCK_DOWN_KERNEL and whatever compile-time
mandatory variants we want, and it adds the helpers so various
subsystems can ask whether lockdown is on.  And it adds one single
lockdown user in the kernel.  And we merge that.  Then we add
additional lockdown users one at a time.

This will resolve what I see as the major issue that has blocked
lockdown: the patchset is too big and spans too many subsystems.
Every time it's submitted it gets bogged down in important but
distracting discussions like "what, exactly, should the following bpf
feature do in lockdown mode?".  These matter, but there is no
legitimate reason for them to block the overall feature -- it's
entirely fine if the initial version of lockdown doesn't protect bpf
at all.

--Andy

[There's only a ~30% change I can make LPC this year...]