Kernel Hardening - security-misc

Development
240

I meant allowing people to choose to disable/enable /home, /boot etc. restrictions (once they’re added) as they wish.

I would prefer to have something periodically check and restrict /boot in case the permissions get changed for whatever reason. If a user wants to have the permissions changed, they can disable permission-lockdown (or change specific settings like I said above).

1 Like
241

Since it’s only done once (and by the time they want to change the setting that setting is already turned on), it’s even easier for them to just change the permissions back to what they want. Thanks to the _done file, the sysadmin won’t be bothered with this ever again.

Why would anything package work on permissions on folder /boot directly? Or what else could change it?

Even if permissions for things inside folder /boot/something change (Debian deciding to change permissions for kernel image or something), that file would stay inaccessible since the root of the folder (i.e. /boot) already has the correct permissions.

If it should be something more periodic…More enforcing…
(Yet configureable. (?))
(And “non-opaque”.)
What about systemd’s /usr/lib/tmpfiles.d mechanism? Also looks quite appropriate?
(No, not just temp files. Yes, some files there configure permissions for persistent folders such as /var/log or /var/cache.)
Would that work?

1 Like
242

What if they don’t remember what the permissions were or aren’t technical enough to change them back to what they want?

I think it would be good to save the default permission and reset it if the user chooses too.

Just in case. E.g. a user’s mistake or misconfigured script can do that.

You wouldn’t want accidental read-write access to kernel images.

Permissions may be more likely to change for other folders we might restrict in the future.

That looks great actually. Seems like a far better approach.

1 Like
243

OpenSUSE actually has a package that changes the file permissions.

https://en.opensuse.org/openSUSE:Security_Documentation

  • the easy profile has a focus on ease of use where more program features work out of the box without the user having to intervene. It also means that there is a larger security attack surface. It can be used for typical single user desktop systems when usability is favored over stricter security.
  • the secure profile is more security oriented and disables certain program privileges. This can result in some program features not being available or behaving less conventiently. It can be used for typical server or multi-user host machines.
  • the paranoid profile is a tightly locked down set of settings that isn’t fully usable in production, because a lot of program features will stop working. This should only be used when security is the major requirement and when you are willing to tune the profile into a state where you can perform the task you want to fullfill with the system.

I can’t find the permissions file anywhere online to see what they do. I’ll setup a VM to check.

1 Like
244

Here is opensuse’s configuration.

permissions.secure: Debian paste error

permissions.paranoid: Debian paste error

2 Likes
245

Awesome find! Can you find the source code? Maybe it can be ported to Debian.

Looks like “/etc/permissions.paranoid” was forgotten. Most search results from year 2002 - 2004. Looks like we’re rediscovering old security knowledge.

1 Like
246

The source only seems to be distributed in .rpm files which I have no idea how to use.

download.opensuse.org/source/distribution/leap/15.0-Current/repo/oss/src/permissions-20180125-lp150.1.2.src.rpm

No, it’s still supported by opensuse. Just doesn’t seem very popular.

1 Like
247

An rpm is similar to a deb. Just an archive with a different file extension. Please open it and look around.

ark permissions-20180125-lp150.1.2.src.rpm

permission.spec

License: GPL-2.0+
Url: GitHub - openSUSE/permissions

source code repository is here:

1 Like
248

Are there any other kernel modules that we could load for better security?

1 Like
249

Last commit on permissions.paranoid was yesterday. Definitely isn’t forgotten.

Dunno why I couldn’t find that repo when searching.

1 Like
250

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
251

What about lockdown lsm?

1 Like
252

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

2 Likes
253

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
254

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
255

Maybe not a blocker.

1 Like
256

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
257

Same in Qubes Debian VM with Qubes VM kernel.

1 Like
258

False-positives.

Probably kernel recompilation required? → kernel recompilation for better hardening

1 Like
259

Hardened usercopy pagespan is only good for debugging AFAIK.

1 Like