Kernel Hardening - security-misc

This wasn’t conclusive debug output.

sudo dmesg | grep lkrg

[   89.832261] p_lkrg: loading out-of-tree module taints kernel.
[   89.850921] p_lkrg: module verification failed: signature and/or required key missing - tainting kernel
[   89.852290] [p_lkrg] Loading LKRG...
[   91.952994] [p_lkrg] LKRG initialized successfully!
[   92.017905] [p_lkrg] Disabling MSRs verification during CI.
[   92.047093] [p_lkrg] [ED] New pCFI configuration => 1 (No stackwalk (weak))
[  510.949628] [p_lkrg] <Exploit Detection> !!! BLOCKING UMH !!!
[  510.949632] [p_lkrg] <Exploit Detection> Someone is trying to execute file: [/bin/false]
[  510.949633] [p_lkrg] <Exploit Detection> --- . ---

sudo sysctl -a | grep lkrg

lkrg.block_modules = 0
lkrg.ci_panic = 0
lkrg.clean_message = 0
lkrg.enforce_msr = 0
lkrg.enforce_pcfi = 1
lkrg.force_run = 0
lkrg.hide = 0
lkrg.log_level = 1
lkrg.random_events = 1
lkrg.smep_panic = 1
lkrg.timestamp = 15
lkrg.umh_lock = 0

grep -r /bin/false /etc/modprobe.d

/etc/modprobe.d/vivid.conf:install vivid /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install dccp /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install sctp /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install rds /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install tipc /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install n-hdlc /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install ax25 /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install netrom /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install x25 /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install rose /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install decnet /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install econet /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install af_802154 /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install ipx /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install appletalk /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install psnap /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install p8023 /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install p8022 /bin/false
/etc/modprobe.d/blacklist-dma.conf:install firewire-core /bin/false
/etc/modprobe.d/blacklist-dma.conf:install thunderbolt /bin/false
/etc/modprobe.d/msr.conf:install msr /bin/false
/etc/modprobe.d/blacklist-bluetooth.conf:install bluetooth /bin/false
/etc/modprobe.d/blacklist-bluetooth.conf:install btusb /bin/false

At least I’d like to know which module specifically was refused loading.

Instead of install vivid /bin/false I tried install vivid /bin/false vivid. I.e. passing a parameter to /bin/false which would be ignored by /bin/false but useful to see in logs. That didn’t work. LKRG won’t show it.

It was security-misc kernel.core_pattern=|/bin/false

Therefore what do you think about changing /etc/modprobe.d/vivid.conf from

install vivid /bin/false

to

install vivid /bin/false_vivid

To a non-existing binary.

Any reason against that?

2 Likes

I’ve renamed / merged some files in security-misc to make these easier to overrule from debug-misc opt-in package to easily enable debugging.

1 Like

If an attacker somehow controls /bin/false_vivid, they can execute arbitrary code as root.

Dunno if an attacker can reasonably control that file though.

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


The sysctl early loading inspired me. Would it make sense to load some kernel modules more early in initramfs too? initramfs supports force_load.

force_load

adds a module (and its dependencies) to the initramfs image and also
unconditionally loads the module during boot. Also supports passing arguments to
the module by listing them after the module name.

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


[1] Though LKRG latter needs to be discussed here Linux Kernel Runtime Guard (LKRG) - Linux Kernel Runtime Integrity Checking and Exploit Detection and/or with upstream due to complexities.)

2 Likes

/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? An attacker can write whatever they want there and it will be regularly executed as root.

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

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

2 Likes

/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.

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:

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:

Also:

2 Likes

Another kernel module as candidate for early loading inside initrd: virtio-rng
Questions: would that break VirtualBox or cause issues on the host?

Or rather than maybe re-inventing a lot things, see if systemd has already overtaken initrd too?

Initrd Interface mentions dracut.

Perhaps better to port Whonix to dracut instead?

Or pass on dracut too and wait until minitrd is available from packages.debian.org?

1 Like

A post was merged into an existing topic: replacing initramfs-tools with dracut

Yes.

That’s probably auto-loaded before initrd anyway.

2 Likes

https://web.archive.org/web/20191031233802/https://systemd.io/RANDOM_SEEDS.html indicates that this is not the case. Quote:

When systemd’s PID 1 detects it runs in a virtualized environment providing the virtio-rng interface it will load the necessary kernel modules to make use of it during earliest boot, if possible much earlier than regular kernel module loading done by systemd-udevd.service. This should ensure that in VM environments the entropy pool is quickly filled, even before systemd invokes the first service process as long as the VM environment provides virtualized RNG hardware (and VM environments really should!).

2 Likes

https://mjg59.dreamwidth.org/54433.html

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

We should consider setting the efi=disable_early_pci_dma boot parameter and CONFIG_EFI_DISABLE_PCI_DMA=y kconfig option for better protection against DMA attacks although these are far ahead of our kernel version.

2 Likes

Good stuff. Please keep it coming. I yet have to read this but one thing…

These could be added now. The existing kernel would probably just ignore these? And when time comes, we haven’t forgotten about this and it’s already check mark done.

2 Likes
1 Like

madaidan via Whonix Forum:

Prevent symlink/hardlink TOCTOU races by madaidan · Pull Request #57 · Kicksecure/security-misc · GitHub

Awesome stuff! Merged too.

1 Like

Something we don’t have yet here?

1 Like

The only things we don’t have are things we’re already discussing (kernel.sysrq=0, kernel.deny_new_usb=1, modules.sig_enforce=1) or things not in our kernel version (init_on_free=1 init_on_alloc=1, lockdown=confidentiality).

Obscurix has other non-kernel-related hardening Whonix doesn’t have like bubblewrap sandboxing though.

Obscurix is my personal project btw. It’s at a very early stage and I’m too busy with other things to work on it more.

2 Likes
2 Likes
2 Likes

We can increase the number of iterations if you want but I think the default is enough (3 passes with random data plus the extra pass with zeroes).

1 Like

madaidan via Whonix Forum:

Restrict loading line disciplines to CAP_SYS_MODULE by madaidan · Pull Request #59 · Kicksecure/security-misc · GitHub

Merged. Could you please expand the description a bit? Add these links
from the pull request? Add a few more keywords such as kernel, console
and what this might break? This is if ever any bug is reported, Whonix
source code can be grepped and this would give a hint.

Seems one of the lesser known hardening options. By performing web
searches other websites come up who are already similarly thorough at
flipping all the security hardening knobs.

Is there something useful here…?

1 Like