“page_poison=1” and the P on the “slub_debug” option are mainly used for Tails’ RAM poisoning. These may improve security anyway by preventing some use-after-free vulnerabilites. These might not work properly in a VM as it doesn’t have access to all of the host’s RAM.
“mce=0” is only useful for ECC memory. It might be good to have just incase but it also might not work properly in a VM.
“vsyscall=none” disables vsyscalls which were removed so this setting is redundant.
The rest except “slab_nomerge” seems to be related to live mode or some other features unrelated to security.
It seems to be enabled by default now. I didn’t know that. I checked Whonix and it’s enabled there too.
Also, one problem with "kernel.dmesg_restrict=1” is that the kernel logs can still be read out by journalctl if the user is part of the systemd-journal, adm or wheel groups. The ordinary user in Whonix is part of the adm group so the kernel logs can still easily be read by an attacker. Maybe there is a way to somehow restrict this even further?
Disabling journald altogether could prevent this but it shouldn’t be done as it’s very useful in debugging errors.
Another way would be to change the permissions for /var/log/journal, /run/log/journal and /bin/journalctl so only root can use it. I don’t know how useful this would be though.
There is an issue on the linux-hardened github repo about this.
For some reason it doesn’t allow me to send the actual link. (Edit by Patrick: link fixed)
Edit: It seems I needed to get the basic badge to send links which I just got.
Since Tails is using most if not all of these configuration changes, shipping these in Whonix might be sustainble (not breaking too many things than current development manpower allows to triage, fix and user support).
I’m not sure if I should add the other boot parameters like page_poison=1 and slub_debug=FZP. What do you think of these? The tails kernel hardening page goes over these.
I can test on Virtualbox and virt-manager (KVM).
Also, regarding the journalctl thing, I’ve made a simple bash script and systemd service that restricts everything to root at boot. It works well and I haven’t gotten any errors yet. Do you think it’d be good to add this to Whonix?
If we must yes. But fixing the original issue above is better. (Since this solution is more fragile - overriding config of with [systemd or whatever that will be in future or ports] tmpfiles.d mechanism.)
adm removal (I will research that too but also speculate pretty sure it will not cause issues - why would it be “standard to be expected” that a linux user is in that group) - If you like please send pull requests:
No, my way would have used a systemd service to restrict the permissions at boot. They get “overrided” as there are new files created at each boot. “mask” prevents the service from ever being started again unless you unmask it.
Well, I was thinking that su and logging in as root would be restricted as well. You can prevent logging in as root from a tty by clearing /etc/securetty and su can be restricted to the sudo group by changing a few permissions. This way root is impossible to get without a root exploit.
That would be interesting but it would be a massive drain on resources and you’d need pretty good hardware if you want to run a lot of apps at the same time.