Kernel Hardening - security-misc

Development
336

If an attacker manages to compromise systemd through a vulnerability (which aren’t exactly rare Freedesktop Systemd : Security vulnerabilities, CVEs).

Since apparmor-profile-everything confines even systemd, our threat model would include preventing a compromised init from attacking the kernel.

I see.

Seems a challenge usability wise. Possible issues:

  • Hardcoded, hard to change sysctl settings, inflexible.
  • Unexpected by users that there are sysctl settings in initramfs.
  • Difficult to change sysctl settings in initramfs.
  • Different settings in initramfs sysctl vs rootfs sysctl creating
    strange, hard to debug situations.

Solvable.

This could consist of various components.

  • sysctl-to-initrd (or so): An initramfs hook which copies
    /etc/sysctl and /etc/sysctl.d (/etc/sysctl(.d)) to initramfs. The
    rootfs /etc/sysctl(.d) would be considered the prime source. initramfs
    /etc/sysctl(.d) would be cleanly created from /etc/sysctl(.d) at
    every run.

  • a dpkg trigger that runs when dpkg modified any files in
    /etc/sysctl(.d) (activate-noawait update-initramfs) (See existing
    Whonix source code for that.) (I can probably do that.)

  • a systemd unit file that runs on shutdown which re-runs
    update-initramfs -u. But only if needed to save re-creating initramfs
    every time. Re-creating initramfs every time non-conditionally increases
    the risk of unclean shutdown of breaking the system and increases
    shutdown/reboot time.

  • maybe better than a systemd unit file would be a inotifywait based
    solution that monitors changes to /etc/sysctl(.d)? Less chance of
    unclean shutdown and destroying initramfs. See whonix-firewall
    /usr/lib/whonix-firewall/firewall-restarter for example use of
    inotifywait. (I can probably do that.) (inotifywait must not
    conflict with the dpkg trigger.)

Initially initramfs-tools based only. Keeping it generic enough so later
support for dracut can be added.

What do you think?

While we are at it, before creating more and more initramfs integration,
are there good reasons to port from initramfs-tools to dracut anyhow? It
would be better to do this sooner than later if there are good reasons
to avoid having to re-implement things later. See also:

I probably could, but sysctls are sprawled all over the kernel source and making all of them read-only would be hard to do and maintaining it would also be hard.

Shouldn’t setting a sysctl be done through an API / function? Then
perhaps only the relevant function would need to be patched for ldsysctl?

1 Like