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

[joeyli <jlee@suse.com>]

Hi,

On Wed, Sep 05, 2018 at 04:01:12PM -0500, Justin Forbes wrote:
> On Wed, Sep 5, 2018 at 3:53 PM, Andy Lutomirski <luto@kernel.org> wrote:
> > 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.
> >
> The Fedora issue was the bpf hammer. I am looking to find a better
> solution for that one, but dropped the patch in the meantime. It was
> removed shortly after it was found.  This is one of the many reasons I
> don't like all or nothing at compile time, but again, we can carry the
> patch to toggle separately until a better solution is worked out.
>

I have thought a approach to give user a fine-grained switch to unlock
individual locked-down function by a authenticatabled function list
blob. The blob must be verified by the keys in kernel trusted keyring
(e.g. kernel compiled-in key or MOK). Maybe add timestamp to prevent
replay attack. Then kernel unlocked functions base on the list in the
authenticatabled blob from user who hosts private key.
 
> > 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.
> >
> I would be fine with this, I just want some sort of path forward.
>

I also agree this approach. At least we can have a simple start in
kernel mainline.
 
> > 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...]
> 
> If you can make it, I will certainly be there and would be happy to
> discuss moving this forward.

Me too.

Thanks a lot!
Joey Lee