Page MenuHomePhabricator

Activating Lockdown
Open, NormalPublic

Description

Consider activating "Lockdown" a mainlined patch that does some hardening measures that including some grsec formerly did. Package currently available only in Sid.

What it does:

  • disables loading/removing kernel modules after boot
  • disables live kernel patching (kexec)
  • disables Berkeley packet filter (BPF)

    (*) No unsigned modules and no modules for which can’t validate the signature.

    (*) No use of ioperm(), iopl() and no writing to /dev/port.

    (*) No writing to /dev/mem or /dev/kmem.

    (*) No hibernation.

    (*) Restrict PCI BAR access.

    (*) Restrict MSR access.

    (*) No kexec_load().

    (*) Certain ACPI restrictions.

    (*) Restrict debugfs interface to ASUS WMI.

While idsabling modules might interfere with non buil-in devices, they can be whitelisted on demand or an extended timeout specified so the needed components are loaded during boot.


https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Lockdown-Patches

https://lwn.net/Articles/719035/

https://packages.debian.org/sid/lockdown

https://gitlab.com/taggart/lockdown


https://forums.whonix.org/t/kernel-hardening/7296

Details

Impact
Normal

Event Timeline

HulaHoop created this task.May 3 2017, 7:09 PM
HulaHoop updated the task description. (Show Details)May 3 2017, 7:11 PM
Patrick added a subscriber: marmarek.

Likely part of 5.2. We won't see it until the version after Buster unless we use backports.

https://www.phoronix.com/scan.php?page=news_item&px=LOCKDOWN-PR-For-Linux-5.2

This looks like focused on kernel protection from attacker having full user (or even root) access already. Something very desirable on server/multi user systems, but not so much meaningful in a single-user AppVM.
Also, disabling modules loading at all may break attaching devices (block, usb etc).
Other than modules loading, it shouldn't harm, though.

Patrick updated the task description. (Show Details)May 3 2019, 6:41 AM

Could you test this please by installing in VM and/or host please? @madaidan

I can test it but I doubt lockdown will help at all.

Copy/paste from what I said on the forums:

I’ve looked at the lockdown code and all it does is change 3 sysctl settings, two of which we already use (in security-misc) and the third one just prevents modules from being loaded after boot which isn’t that much of a security gain.

Either, I’m missing something massive or lockdown is mostly useless for us.

It turns out, what I said only applies to the Debian package. The kernel patch and the package are actually two different things.

Many of the things in the kernel patch are already enabled by default or are enabled in security-misc. There's very little advantage.

Also, Daniel Micay has interesting things to say about lockdown.

https://twitter.com/DanielMicay/status/1180072339112898562

Almost entirely security theater with no real impact. Not relevant in any way to solving these kinds of problems or mitigating kernel vulnerabilities. It's based around providing a bogus, incomplete form of secure boot not actually providing any real security value to end users.

It's a marketing-focused, incomplete and useless approach to secure boot. The total value of it is negligible and it's very unfortunate that it's all grouped together as part of something that's almost completely nonsense with no real threat model or use case thought out for it.