Restrict Hardware Information to Root - Testers Wanted!

Yes, that’d be a good idea.

1 Like

This was done:
Reduce Kernel Information Leaks

1 Like

Is this recommended for increase anonymity? i see that it breaks applications that why I’m 50 50 on it. Should the risk he taken for the anonymity (want as much anonymity as possible)

Using: Qubes-whinox

That is already documented here:

This link has been notorious for not working for me. I checked out the GitHub for it though. All it says is what I have already said. I’m asking if whinox is still usable in particular qubes-whinox with it install, I don’t see any feedback on what exactly it breaks and if it’s worth it even with its security benefits to have it install, all I have seen is bug fixes from users.

It’s testers-only.

Good afternoon.
I would like to hide the kernel version and CPU model from applications using security-misc. When I activate “sudo systemctl enable hide-hardware-info.service” and after further reboot, the system turns on, but other than mouse movements, I can’t do anything else with it. It does not react to anything, even to the commands ctrl+alt+delete and ctrl+alt+f1-12, the exception - the button to shut down the virtual machine.
Experimentally found that if you add user to group sysfs through the command “sudo addgroup user sysfs” - the system is fully operational and even hidden CPU characteristics from applications. But the kernel version information still escapes to the public, strangely enough.
How can I make the kernel information to be hidden at least from third party applications? I should point out right away that I am far from IT and how linux operating system works.
I tried running the systemd service as a sysfs group by creating a drop-in directory, but it didn’t work. Probably because I did it wrong. I created the directory “systemd.d” in the folder “etc” and added files called “sysfs.conf” and “50_user.conf” with the contents of “[Service]
SupplementaryGroups=sysfs”, it had no effect. Also in the /etc/systemd/ directory I added all the same content to the “system.conf” and “user.conf” files, and the result was the same. Adding new files “sysfs.conf” and “50_user.conf” to this same directory also failed.

I should add that these problems equally apply to whonix on kvm and version on virtualbox.
In turn, security-misc, installed on a clean debian 11.3.0 xfce image on kvm showed full functionality from the first time without any tinkering.

working fine (tested in qubes) except it all add additional boot delay

1 Like

This needs some documentation how to test this:

1 Like

CPUID is now documented on a dedicated wiki page.

The wiki page

also mentions “Cannot hide CPUID.”

Now documented.

I was able to fake CPUID on VirtualBox using vboxmanage. Then I found

Anyway, for the record:

set vm=“Whonix-Gateway-XFCE”
vboxmanage modifyvm %vm% --paravirtprovider none
vboxmanage modifyvm %vm% --cpuidremoveall
vboxmanage modifyvm %vm% --cpu-profile “Intel Core i7-5600U”

Breaks flatpak.

flatpak run org.chromium.Chromium

bwrap: Can’t find source path /sys/block: Permission denied

I don’t see a lot spoofing there. It might make you stand out more unless you could come up with a way to spoof more information.

Never mind “cat /proc/cpuinfo” for now. See: /proc/cpuinfo versus cpuid (written just now).

Instead, try using cpuid (which gets the information directly from the CPU):
cpuid usage

Then compare using CPUID Spoofing Testing (written just now).

1 Like

I don’t see a lot spoofing there. It might make you stand out more unless you could come up with a way to spoof more information.

I can certainly do some more spoofing, like reporting a Pentium D. But it’s pointless, you don’t need CPUID to detect some features.

You mean that all CPU spoofing attempts are currently futile? I’d agree.

1 Like

In Vbox will cause dysfunctional of xfce Restart and Shut Down buttons (user will need to CLI commands to achieve the same missed GUI buttons effect).

1 Like

breaks flatpak: