Activating Lockdown

[phabricator-migrator]

Information

ID: 670
PHID: PHID-TASK-l4gmuy3cuov3icsa3hqv
Author: HulaHoop
Status at Migration Time: open
Priority at Migration Time: Normal

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.

---

Kernel Lockdown: Tightening Up Linux Kernel Access From User-Space

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

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

Matt Taggart / lockdown · GitLab

---

Kernel Hardening - security-misc

Whonix should implement more kernel hardening. All of these settings add no or a very minimal performance decrease. Setting “kernel.kptr_restrict=1” makes kernel symbols in /proc/kallsyms only accessible to root which can make it more difficult for a kernel exploit to resolve addresses/symbols. Setting it to 2 hides the symbols regardless of privileges. Setting “kernel.dmesg_restrict=1” restricts access to the kernel logs which can give an attacker less information on what they can do. Setti…

Linux Lockdown Kernel Parameter

Draft manpage explaining kernel lockdown https://lwn.net/Articles/735564/ EDIT: moved to its own thread to make this more easy to find for reference

Comments

---

HulaHoop

2019-03-29 03:39:21 UTC

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

LOCKDOWN Aiming To Be In Linux 5.2 For Tightening Up Hardware/Kernel Access - Phoronix

---

Patrick

2019-04-04 18:14:57 UTC

Any opinion? @marmarek

---

marmarek

2019-04-04 18:51:48 UTC

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.

---

HulaHoop

2019-05-03 16:14:01 UTC

Related thread on general kernel hardening:

Kernel Hardening - security-misc - #9 by madaidan

---

Patrick

2019-05-05 21:28:00 UTC

More kernel hardening:
More kernel hardening by madaidan · Pull Request #5 · Kicksecure/security-misc · GitHub

---

Patrick

2019-07-03 06:45:35 UTC

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

---

madaidan

2019-07-03 14:58:56 UTC

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.

---

madaidan

2019-10-04 18:37:46 UTC

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.