Kernel Hardening - security-misc

https://wiki.gentoo.org/index.php?title=Hardened_Kernel&oldid=638760

CONFIG_PAGE_POISONING forces debug infrastructure bloat, slab poisoning via slub_debug=P disables the slub fast path which is unnecessarily, ridiculously slow + always enables verification which can be a nice security feature but hurts performance more. It also forces the freelist pointer after the allocation, which is a security improvement in terms of mitigating use-after-free but wastes memory (PaX leaves it inline now unlike in the past and just sanitizes the rest). It also uses a poison value resulting in pointers pointing to userspace - quite dangerous without UDEREF, and still a bad idea with it present.

Seems like init_on_free is more secure and has better performance.

init_on_{free,alloc} don’t seem to have sanity checks though (page poisoning does). linux-hardened solves this with CONFIG_PAGE_SANITIZE_VERIFY and CONFIG_SLAB_SANITIZE_VERIFY.

Btw the init_on options are basically PAX_MEMORY_SANITIZE AFAIK (what the link is comparing page poisoning to).

1 Like

What about lockdown lsm?

1 Like

Lockdown is about to be incorporated in the kernel itself if not already AFAICT.

2 Likes

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d

How to use it?
Should we use it?

1 Like

Lockdown is nice but it doesn’t do much. It’s only focused on making it harder for root to escalate to kernel code but most of the things it does can already be done without lockdown.

It’s mostly just marketing. Most Linux users won’t benefit from it anyway as an untrusted root user isn’t part of their threat model (although it is part of ours).

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

It’s only available in linux 5.4 which is far away from the debian stable kernel.

2 Likes

Maybe not a blocker.

1 Like

Qubes Debian VM with Qubes dom0 kernel.

sudo checksec --kernel
  • Kernel protection information:

    Description - List the status of kernel protection mechanisms. Rather than
    inspect kernel mechanisms that may aid in the prevention of exploitation of
    userspace processes, this option lists the status of kernel configuration
    options that harden the kernel itself against attack.

    Kernel config:
    /proc/config.gz

    Vanilla Kernel ASLR: Full
    Protected symlinks: Enabled
    Protected hardlinks: Enabled
    Ipv4 reverse path filtering: Disabled
    Ipv6 reverse path filtering: Disabled
    Kernel heap randomization: Enabled
    GCC stack protector support: Enabled
    GCC structleak plugin: Enabled
    GCC structleak by ref plugin: Enabled
    SLAB freelist randomization: Enabled
    Virtually-mapped kernel stack: Enabled
    Enforce read-only kernel data: Enabled
    Enforce read-only module data: Enabled
    Exec Shield: Disabled

    Hardened Usercopy: Enabled
    Hardened Usercopy Pagespan: Disabled
    Harden str/mem functions: Enabled
    Restrict /dev/mem access: Enabled
    Restrict I/O access to /dev/mem: Enabled
    Restrict /dev/kmem access: Enabled

  • X86 only:
    Address space layout randomization: Enabled

  • SELinux: Disabled

    SELinux infomation available here:
    http://selinuxproject.org/

  • grsecurity / PaX: No GRKERNSEC

    The grsecurity / PaX patchset is available here:
    http://grsecurity.net/

1 Like

Same in Qubes Debian VM with Qubes VM kernel.

1 Like

False-positives.

Probably kernel recompilation required? → kernel recompilation for better hardening

1 Like

Hardened usercopy pagespan is only good for debugging AFAIK.

1 Like
1 Like

5 posts were split to a new topic: enable reverse path filtering

Something we don’t have yet here?

1 Like

Doesn’t seem to have anything we don’t have.

1 Like

Also, some systems don’t store the System.map file in /boot but in files such such as /lib/modules/*/*/System.map or /usr/src/*/System.map.

If we were to remove read access to kernel images in /boot for non-root users, then we’d also need to remove read access to files like /usr/src/*/vmlinux and /vmlinuz.

2 Likes
2 Likes

Instead of porting opensuse’s stuff to Debian, we can make our own simpler solution like Debian paste error

Config files would look like Debian paste error

1 Like

Commented inline on github.

Really good approach.

(Although might have some nitpicks. mywiki.wooledge.org might say for line in $(cat ${config_file}) isn’t secure. Never mind. Please send a pull request. I’ll add any parsing enhancements on top.)

dpkg-statoverride should be used, though. Ideally as replacement for chmod/chown - if that is possible. But surely in combination with dpkg-statoverride. Because when packages are updated, these permissions will be reset- By using dpkg-statoverride, permissions will always be consistent what we want - even if packages are updated.

2 Likes

I was testing around with file capabilities and did some grep hackery to add a [Capabilities] sections where we can specify file capabilities.

What do you think of Debian paste error?

Example of a config file: Debian paste error

Would

while read line; do command; done <${config_file}

be better?

Should it also use a systemd service so these permissions are always set at boot regardless?

If users need to, they can disable the service or add a permission-hardening.d file for custom permissions.

1 Like

It’s a good list, and as @madaidan said, Whonix implements pretty much all of it. We do not have separate partitions, but we restrict the permissions.With restricted root and the other Whonix protections, there is good security.

2 Likes