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
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?
/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?).
/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:
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!).
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.
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.
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.
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.