/etc/sysctl.d by Tails:
Tails kernel boot parameters. (source)
AMNESIA_APPEND=“live-media=removable nopersistence noprompt timezone=Etc/UTC block.events_dfl_poll_msecs=1000 splash noautologin module=Tails slab_nomerge slub_debug=FZP mce=0 vsyscall=none page_poison=1 union=aufs”
Some do not apply to Whonix since these are only related to live mode.
Was dropped by Tails.
“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).
The https://github.com/Whonix/security-misc package looks like the right place to add these.
/etc/sysctl.d configs could be dropped here (maybe copy over from Tails verbatim as much as makes sense): https://github.com/Whonix/security-misc/tree/master/etc/sysctl.d
kernel boot parameters could be modified by shipping a configuration snippet similar to https://github.com/Whonix/grub-enable-apparmor/blob/master/etc/default/grub.d/30_apparmor.cfg (perhaps simpler) could be dropped into security-misc too. (One kernel boot parameter per one line if good.)
Users might manually do this as per https://www.whonix.org/wiki/Documentation but I don’t think this is sustainable for default installation in Whonix with current developer manpower since the package is not available from packages.debian.org, see also:
(Kernel is not an “app” but stuff written there applies here too.)
Will I create a pull request for these or something else?
How would hidepid be added if at all?
madaidan via Whonix Forum:
Will I create a pull request for these or something else?
For /etc/sysctl.d and /etc/default/grub.d (and perhaps /etc/modprobe.d
How would hidepid be added if at all?
Please test if it works. If yes, we can take it too.
Which platforms could you test?
virtualbox-guest-additions in Whonix VirtualBox shouldn’t break by this.
(Then things would get more complex - another package or if/else code if
I’ve created the pull request.
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?
Both of these are Grsec features ported by KSPP to the mainline kernel and they seem very useful for mitigating memory corruption:
If you can document how to disable it for debugging purposes then sure.
Looks really good at first! Will probably be merged soon.
Haven’t seen anything negative about these. Why not. Yes, please add.
Awesome, that helps a lot! I’ll test in Qubes first.
Can be considered but I am not sure that would be a clean implementation. Rather, I would like to possibly fix the original cause of these issues. Will answer more soon.
adm is from here: https://github.com/Whonix/anon-base-files/blob/master/debian/anon-base-files.postinst#L67
That code was carried around probably from the early TorBOX script version and never been questioned unfortunately.
usermod --append --groups adm,cdrom,audio,dip,sudo,plugdev user || true
Maybe that has to be reworked. Should we remove some user groups, we can modify that for existing users to in whonix-legacy package (using the “do only once” style).
Could you please try removing user
adm (and whatever else seems to make sense) and see how that works generally?
What’s next? Suggest removal of user
user being in group
sudo by default?
https://www.whonix.org/wiki/Dev/Permissions i.e. how well can linux protect from root privileged escalation after user
user account was compromised (by a remote code execution vulnerability).
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.)
I’ve added the other kernel parameters. They seem to work well with Whonix. I haven’t had any problems.
You just need to disable/mask the systemd service and revert the files to back the original permissions.
systemctl mask restrict-journalctl.service chmod 2755 /run/log/journal chmod 2750 /run/log/journal/* chmod 640 /run/log/journal/*/* chmod 755 $(which journalctl)
I’ll test that now on the Gateway and Workstation. I’m not sure what purpose adm has except for the journal.
Well for a completely locked down system, that would actually be good. Just make a systemd service for updating at boot. It’d be incredibly difficult to use properly though.
I agree. My way would probably break a lot of things.
It seems the adm group is only used for viewing log files. Removing this shouldn’t cause problems.
Removing the user from the adm group works perfectly. I get an error when running
journalctl and I can’t view the log files manually. There are no other errors.
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:
Running journalctl as with root/sudo is fine. No need to run as user
That might be a typo?
Please create a separate forum thread for that.
Ideally, address for added motivation:
Some or even all of above could get invalid with the inception of wayland and/or not apply for CLI or non-gui linux users such as user
Updating, you mean
I am not sure I understand that one. Difficult to use since one would require another login session to run commands as root (indeed) or use
su or something like that?
This would also kinda be a prerequisite for something I am sometimes briefly wondering about:
walled garden, firewall whitelisting, application whitelisting, sudo lockdown, superuser mode, protected mode - in essence: can a VM be restricted to be running “a single application and nothing else let alone sudo”?
I’ll create a pull request now.
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.
I managed to get hidepid working.
In /etc/fstab, add
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
Make /etc/systemd/system/systemd-logind.service.d/hidepid.conf and add
Now create the ‘proc’ group by running
systemd-logind works fine and I haven’t got any errors so far.
The problem last time was that I didn’t create the ‘proc’ group.
What package could this be added to?
The nitpick first before addressing the actual real and hard question:
/lib/systemd/system/ instead as per
Good question, next question.
Non-Qubes-Whonix: file owned by nobody, created by grml-debootstrap at image creation and then left alone.
Qubes-Whonix: as per Qubes default:
dpkg -S /etc/fstab
The Qubes version is much different.
So this would require a new package which get installed in Non-Qubes-Whonix only to avoid package conflict. (And Qubes would require a separate issue and pull request [which is optional].) We don’t have such a package yet.
I am not sure if by introducing such a package we might break user customization for people who modified /etc/fstab but probably not and for Whonix 15 upgrade this is ok (and still in time).
Any naming suggestion for such a package? It’s not just
hidepid, perhaps later other fstab hardening? It’s general security also, not hardcoded for Whonix.
Can we use
/etc/fstab.d rather than
/etc/fstab while we are at it?
/etc/fstab would be really bad since it has to be complete which then might make it (Whonix|hardended debian) VM specific.
/etc/fstab.d would be super helpful if we could just harden/reconfigure
/proc rather than shipping a complete
/etc/fstab. (Then probably even Qubes compatible.) In that case we could even add this to
security-misc package too.
I don’t think this really matters. Both should work fine.
fstab hardening would be a good name for it. It could also be used to set different mount options for different file systems like nosuid, nodev or noexec.
I haven’t ever heard of a /etc/fstab.d. It seems that support for it was abandoned.
Maybe we could ask them to see if they’ll ever bring support for it back?
A quick and dirty method would be
sed -i 's/proc/#proc/' /etc/fstab; echo "proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0" >> /etc/fstab
This is terrible though and should only be used as a last resort.