Grsecurity had a feature that restricted access to /sys to root only. This would help hide most hardware information from ordinary users except information in /proc.
There is a pull request to linux-hardened that provides an equivalent to this but it has not been accepted yet.
There was also a feature that hid a lot of information in /proc to non-root users. As far as I know, there is no equivalent to this in linux-hardened.
https://forums.whonix.org/t/anonymize-etc-machine-id/7721/21
I’m currently working on a script that does this. So far, I’ve gotten it to hide CPU, motherboard/BIOS, USB and PCI information to unprivileged users.
Can you please make sure this doesn’t break virt-detect that Whonixcheck uses to know if a hypervisor is supported? Also used for shared folder daemons.
Currently, that isn’t broken.
Because that has a sudoers exception.
Btw this can also be used to hide things like CPU info in /proc/cpuinfo or other stuff in /sys. Or we can use it to restrict hardware info to root by copying the file to a different location, changing the file’s permissions and then bind mounting it back to the original file.
Why over mount if we could just change access rights to prevent user from reading?
I was under the impression that you couldn’t change the file permissions directly but I just tested it and it does work without overmounting.
In that case, we can just do chmod og-rwx -R /sys. Not only would this hide a whole load of hardware information, it would also prevent a bunch of security vulnerabilities as sysfs and debugfs add a lot of attack surface.
As per Grsecurity/Appendix/Grsecurity and PaX Configuration Options - Wikibooks, open books for an open world we can whitelist /sys/devices/system/cpu
Running chmod og-rwx -R /sys at boot with a systemd service breaks dbus-launch so XFCE can’t start.
If this is going to be implemented we’d need to add exceptions or set it after XFCE has started.
Whitelist better.
XFCE bug report?
Any other upstream to discuss with?
If it breaks XFCE it probably is breaking a ton of other things too. (GNOME, KDE, …?)
After $something starter is never great since this leaves room for race conditions where some daemon (for example web server) starts earlier than this.
Also since this is to prevent malware from getting root this might happen too late to help.
How exactly would that be implemented?
I’m thinking of making /sys owned by a sysfs group and making binaries that need /sys owned by the sysfs group and setgid so it would run with the permissions of the sysfs group.
I don’t really see this as a bug. There are many legitimate uses for /sys. If not, it wouldn’t be a thing in the first place.
It would break a ton of things.
The grsecurity devs even said it shouldn’t be used on desktops due to the amount of things that would break
https://forums.grsecurity.net/viewtopic.php?t=4655
it shouldn’t be enabled on desktops
I think the security/privacy benefits are too great to not enable it though. It could even be optional and documented in Whonix-Workstation Security Hardening - Whonix
Also, more examples of breakage:
https://wiki.gentoo.org/wiki/PulseAudio#grsec_and_PulseAudio
I managed to fix XFCE just by installing the dbus-x11 package.
XFCE kept breaking with an error about /usr/bin/dbus-launch terminating but that didn’t exist so I installed the dbus-x11 package and it somehow worked. I have no idea why this fixed it.
Now whonixcheck is breaking as it tries to check if the network interface is up by running cat /sys/class/net/eth0/carrier. This can be fixed by just making whonixcheck do something like grep ip a output.
Grepping the whonixcheck source code shows that it also tries to do something with /sys/devices/system/clocksource/clocksource0/current_clocksource which would also break. Dunno how this could be fixed.
madaidan via Whonix Forum:
Now whonixcheck is breaking as it tries to check if the network interface is up by running
cat /sys/class/net/eth0/carrier. This can be fixed by just making whonixcheck do something like grepip aoutput.Grepping the whonixcheck source code shows that it also tries to do something with
/sys/devices/system/clocksource/clocksource0/current_clocksourcewhich would also break. Dunno how this could be fixed.
Use sudo cat and adding a sudoers.d exception.
It shouldn’t break XFCE startup just because some file in sys is missing.
Sounds good.
https://github.com/Whonix/whonixcheck/pull/12
https://github.com/Whonix/anon-meta-packages/pull/21
How would hide-hardware-info.service be disabled by default? Is adding systemctl disable hide-hardware-info.service to debian/security-misc.postinst enough?
Major: Could you please add the licensing header to the new files?
Minor: Could you please add --non-interactive after sudo, i.e.
sudo --non-interactive
for the new whonixcheck sudo commands? (I can also add this on top.)
systemd preset could be the correct mechanism for that? Never used myself yet.
systemd.preset(5) — systemd — Debian stretch — Debian Manpages any help?
Debian debhelper fortunately supports systemd preset nowadays. At least a short look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772555 implies so.
systemd-preset is used by a few packages in Debian. To learn the syntax / compare, perhaps have a look at a few of such packages?
Looks like a snippet in in file
/lib/systemd/system-preset/50-security-misc.preset
with contents
disable hide-hardware-info.service
+ licensing header.
Just did those.
What’s the point of --non-interactive? sudo already runs without prompting if there’s a sudoers exception.
sudo --non-interactive
sudo in whonixcheck.For now whonixcheck sudoers file is fairly stable but in past it got improved, more hardened. In future the way whonixcheck / sudo works may be improved. I was thinking user user should be able to run whonixcheck without sudo since it could show logs which might contain information which a user might not want to see. (Relatively minor since we probably don’t have many users following advice of Safely Use Root Commands) So changes to whonixcheck suoders file in future are possible. In past whonixcheck suoders file was modified by third parties (Qubes-VM-Hardening).
Installing dbus-x11 might not be the best way to fix XFCE.
dbus is handled by systemd, and has been for a long time. Don’t use dbus-launch