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.
group 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 user from 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? 
Strong Linux User Account Isolation 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 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 sdwdate.
Updating, you mean apt-get dist-upgrade?
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.
Yes.
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
[Service]
SupplementaryGroups=proc
Now create the ‘proc’ group by running
groupadd proc
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:
should be /lib/systemd/system/ instead as per
Dev/About Debian Packaging - Kicksecure
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
qubes-core-agent: /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.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663623
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.
Yes, please.
Indeed. (There is also config-package-dev transform but only slightly less terrible, I guess.)
Alternative much better idea in theory #1:
systemd unit file (that runs very early after fstab processing) which uses mount (remount) on /proc if that is possible? That could be part of security-misc package. Only remounts /proc for start (perhaps later more). Name of systemd unit file: security-misc-early.service? Automatically Qubes compatible / working in Qubes too, working on all supported platforms actually.
Alternative much better idea in theory #2:
Also a search for systemd fstab looks like systemd does a lot related to fstab. If above does not work, perhaps there would be any useful hook to overwrite what is written in /etc/fstab so we don’t have to touch that file.
Will I file a bug report?
That sounds not too bad. We could make it run a bash script that can even configure other directories. It could be confusing for people trying to change their mount options though.
I’ll look into this and see what I can find.
Alternative much better idea in theory #3:
Use a systemd .mount file. You seem to configure it just like a systemd service. Configure /proc and add Options=nosuid,nodev,noexec,hidepid=2,gid=proc. I don’t know much about these though. See:
https://www.freedesktop.org/software/systemd/man/systemd.mount.html
Edit: This seems like a good guide for #3
Also, there are more sysctl changes that’d be good to add.
Setting “kernel.kexec_load_disabled=1” will disable kexec which can be used to replace the running kernel.
Setting “net.ipv4.tcp_rfc1337=1” protects against time-wait assassination. It drops RST packets for sockets in the time-wait state.
Setting "net.ipv4.conf.default.rp_filter=1 and “net.ipv4.conf.all.rp_filter=1” enables source validation of packets and protects against IP spoofing methods in which an attacker can send a packet with a fake IP address.
Setting
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.default.secure_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.default.accept_redirects=0
disables ICMP redirect acceptance. If these aren’t set then an attacker can redirect an ICMP request to wherever they want.
Setting “net.ipv4.conf.all.send_redirects=0” and “net.ipv4.conf.default.send_redirects=0” disable ICMP redirect sending.
Setting “net.ipv4.icmp_echo_ignore_all=1” makes your system ignore ICMP requests.
Setting “kernel.yama.ptrace_scope=2” restricts the use of ptrace to root. Ptrace allows a program to alter and inspect a running process.
Should I add these to the pull request?
Yes, that would be great!
Indeed and it could even be made configurable.
If that works, that would be the most appropriate tool for the task. Ideally (and quite likely supported by systemd), a drop-in configuration snippet.
This for sure can only be done by root and root could disable this. So I don’t see any advantage by it.
Likely yes, let’s have a few days time pass for research and eventual comments.
kernel.unprivileged_bpf_disabled=1
Could you please try to find out why Tails isn’t using that anymore (they did so in past looks like).
No luck:
site:tails.boum.org "kernel.unprivileged_bpf_disabled=1"
site:https://git-tails.immerda.ch "kernel.unprivileged_bpf_disabled=1"
More kernel hardening by madaidan · Pull Request #5 · Kicksecure/security-misc · GitHub merged just now.
Tails has more files in their /etc/sysctl.d. Could you please look through the other /etc/sysctl.d snippets that Tails has that we don’t have? And copy over anything relevant so we’re on par with Tails? (Please keep same file names as Tails for simplicity/comparison (as far as that makes sense but I guess so)).
Thanks for all the hard work you’re putting into Whonix! Looking forward to your enhancements in the Whonix code. If I can do anything for you, please let me know!
Which package and version would it be?
I’m having problems with it on Whonix. It doesn’t seem to want to mount /proc. I’ll try and see if it can be done.
Tails disables it anyway and the KSPP recommends it.
I’ve just created it.
It looks like Tails still uses it
Great!
Tails uses “net.ipv4.tcp_mtu_probing=1” which seems to just be for obfs4 bridges
They also use “fs.protected_fifos = 2” and “fs.protected_regular = 2” but I don’t know what this does.
The rest we already have or is in the new pull request I made.
Thanks!
util-linux upstream I guess it is here:
systemd/sysctl.d/50-default.conf at main · systemd/systemd · GitHub is using it but I don’t know in which cases this file gets installed on a system. Debian does not seem to ship it, yet looks interesting. Could you have a look please?
https://outflux.net/blog/archives/2018/10/22/security-things-in-linux-v4-19/
Sounds good to have. Could you add please too?
dpkg -S protect-links.conf
procps: /etc/sysctl.d/protect-links.conf
cat /etc/sysctl.d/protect-links.conf
###################################################################
# Protected links
#
# Protects against creating or following links under certain conditions
# Debian kernels have both set to 1 (restricted)
# See https://www.kernel.org/doc/Documentation/sysctl/fs.txt
fs.protected_hardlinks = 1
fs.protected_symlinks = 1