Kernel Hardening - security-misc

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

madaidan via Whonix Forum:

Avoid holes in IOMMU by madaidan · Pull Request #61 · Kicksecure/security-misc · GitHub

Merged.

1 Like

madaidan via Whonix Forum:

Shred System.map files by madaidan · Pull Request #62 · Kicksecure/security-misc · GitHub

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 ⚓ T960 hardened kernel Debian packaging and APT integration - hkapt 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

Do you have good references to warn against nested virtualization?

1 Like

I added “TTY” which should be enough. This shouldn’t really break anything for ordinary users.

The only others who use this that I know of are CLIP OS.

I don’t know much about that. @HulaHoop might.

Doesn’t seem to be anything we don’t already have/not in our kernel version/we’re already working on.

Unrelated, but we might want to use the extra_latent_entropy boot parameter. linux-hardened adds an optional feature to gather more entropy although at a boot speed decrease Add the extra_latent_entropy kernel parameter · anthraxx/linux-hardened@0ca98c2 · GitHub

1 Like

madaidan via Whonix Forum:

Document ldisc_autoload better by madaidan · Pull Request #63 · Kicksecure/security-misc · GitHub

Merged.

1 Like

Sounds good! Please add.

Related:

1 Like

The presentation on the vivid bugs discussed a while ago.

security-misc blacklists the module, hardened-kernel doesn’t include vivid or userfaultfd() (which was used to exploit these bugs) at all, and both restrict the kernel logs to root which mitigates this on multiple layers (although vivid wasn’t removed until these bugs were disclosed).

1 Like

I’m not aware of it ever being mentioned as adding extra attack surface or aiding spectre/meltdown. Have you seen anything? If yes I can try harder to search for it.

2 Likes