Restrict hardware information to root

I am not sure sound quite feature request alike / request for change of defaults alike. Let’s see what they say.

Alternatively, subject:

prevent non-root users from viewing hardware information from /proc/cpuinfo, /bin/lspci and /sys

text:

possibility of this being an identifier

Not sure they care. Can we make this a security argument? Principle of least privilege? What’s the use case for non-root users to view hardware information?

1 Like

Hardware information may be useful for an attacker to know what exploits in some firmware to use.

They could probably detect the firmware by seeing what modules are loaded though.

If your adversary is one with lots of resources then knowing the hardware may help in utilizing potential hardware backdoors. A bit extreme but seems possible.

1 Like

I don’t believe I was not aware of that.
What’s the situation with Qubes and KVM?

1 Like

See:

1 Like

From the comments,

KVM = Spoofed the CPU :white_check_mark:

Virtualbox = Failed to do that :heavy_multiplication_x:

Qubes = The most failure :x:

I am not sure if anything has changed.

At the moment I pass thru all CPU flags from the host to the guest to allow the guest kernel spectre/meltdown protections to kick in. Restricting this info to root is a great step.

Also preventing unprivileged processes from enumerating info from /proc/pid does make it harder for rowhammer attacks:

1 Like

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