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.
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 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.
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
Restricting /proc/cpuinfo to root breaks the start-tor-browser script. It exits with an error saying “Tor Browser requires a CPU with SSE2 support.”.
In /home/user/.tb/tor-browser/Browser/start-tor-browser
there is:
if ! grep -q '^flags\s*:.* sse2' /proc/cpuinfo; then
complain "Tor Browser requires a CPU with SSE2 support. Exiting."
exit 1
fi
There were no other errors after I commented out that piece of code.
We’ll need to somehow patch this to run that code only if hide-hardware-info.service is not enabled or give another sudoers exception.
systemctl is-active
would be perfect for this except it only checks if the service is currently active and not if it has already succeeded.