Kernel Hardening - security-misc

[Patrick]

@Patrick

Attackers have exactly as much or as little control over /bin/false too?

/bin/false already exists and has its permissions correctly set.

I don’t really like the idea of it pointing to an unknown file. What if /bin/false_vivid already exists but with 777 perms?

Nothing in /bin does ever exist (without previous system compromise or created by system administrator) that has permissions 777 (i.e. writeable by others than root). Any argument against /bin/false_vivid could also be made against /bin/false.

An attacker can write whatever they want there and it will be regularly executed as root.

@Patrick

Useful kernel modules come to mind could be jitterentropy_rng and LKRG [1]. Others?

jitterentropy should be built-in, not a module. We already do that with hardened-kernel though.

Alright.

However, as long as we’re not using hardened-kernel by default and for non-users of hardened-kernel, does it make sense the load jitterentropy_rng more early?

See also:

load jitterentropy_rng kernel module using the kernel command line / kernel built-in jitterentropy_rng?

jitterentropy_rng is currently only used by the in-kernel DRBG.

What uses the in-kernel DRBG? Asked in above ticket too.

LKRG and tirdad should be loaded as early as possible. Preferably, they would also be built-in but that’s not supported (yet?).

tirdad statically in kernel, asked upstream, link here:

TCP ISN CPU Information Leak Protection - tirdad - #7 by Patrick

Also:

TCP ISN CPU Information Leak Protection - tirdad

Why should tirdad be loaded as early as possible? Currently tirdad is loaded before networking comes up through systemd-modules-load.service.

Also:

Linux Kernel Runtime Guard (LKRG) - Linux Kernel Runtime Integrity Checking and Exploit Detection

As for LKRG loading it as early as possible is non-trivial. Currently loading LKRG as early as possible would cause some issues. For example it would detect changes by tirdad as malicious and show a lot false positive messages. Asked upstream about it: Compiling LKRG static into the Kernel / Loading LKRG kernel module as early as possible or after other modules?