[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Kernel Hardening

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

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?

https://systemd.io/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:

https://github.com/Whonix/security-misc/pull/57

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:

https://github.com/Whonix/security-misc/pull/59

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

madaidan via Whonix Forum:

https://github.com/Whonix/security-misc/pull/61

Merged.

1 Like

madaidan via Whonix Forum:

https://github.com/Whonix/security-misc/pull/62

Merged.

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

Yes, that is OK. (Much more important to compile the kernel on the
user’s machine and never write a system.map file in first place but that
takes a while until https://phabricator.whonix.org/T960 is done.)

“rm --verbose” was OK (I like these features to self-document) but
“shred --verbose” is a bit too chatty. Example:

shred --verbose --force --zero -u /tmp/a
shred: /tmp/a: pass 1/4 (random)…
shred: /tmp/a: pass 2/4 (random)…
shred: /tmp/a: pass 3/4 (random)…
shred: /tmp/a: pass 4/4 (000000)…
shred: /tmp/a: removing
shred: /tmp/a: renamed to /tmp/0
shred: /tmp/a: removed

Changed:

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]