Restrict hardware information to root

Protocol Leak and Fingerprinting Protection‎ needs update then?

Yes though I need someone who doesn’t mind posting their CPU info on there. @nurmagoz can you please repeat the /proc/cpu tests and update the wiki?

2 Likes

For all hyporvisors or kvm only ?

2 Likes

KVM only.
VirtualBox when you get to it but I guess nothing changed.
In Qubes nothing changed either as far as I know.

1 Like

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.

https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sysfs/debugfs_restriction

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://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Restrict_/proc_to_user_only

1 Like

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.

2 Likes

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.

1 Like

Currently, that isn’t broken.

1 Like

Because that has a sudoers exception.

2 Likes

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.

1 Like

Why over mount if we could just change access rights to prevent user from reading?

1 Like

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

1 Like

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.

1 Like

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.

1 Like

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

1 Like

Also, more examples of breakage:

https://wiki.gentoo.org/wiki/PulseAudio#grsec_and_PulseAudio

2 Likes

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.

1 Like

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 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.

Use sudo cat and adding a sudoers.d exception.

1 Like

It shouldn’t break XFCE startup just because some file in sys is missing.

Sounds good.

1 Like

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?

1 Like