I am not an Intel processor guru and I don’t even play one on TV… but I can’t imagine how else you could keep a program from getting information that’s handed out directly by an unprivileged CPU instruction.
Thanks for telling me about this. I’ll look into it further.
The only thing I can find about this is https://security.stackexchange.com/questions/220357/fake-output-of-cpuid-instruction
Maybe there’s a way to patch KVM on the host to fake the CPUID instruction.
The relevant code seems to be https://github.com/torvalds/linux/blob/master/arch/x86/kvm/cpuid.c
i tested it in the workstation on kvm. indicator is providing the appropriate notifications.
Have had the service enabled for the last two days on Qubes-Whonix 15, no problems so far. Everything works properly.
I have started and enabled the service but it doesnt seem to work.
sudo systemctl status hide-hardware-info.service
● hide-hardware-info.service - Hide hardware information to unprivileged users
Loaded: loaded (/lib/systemd/system/hide-hardware-info.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Thu 2020-07-09 13:58:08 EEST; 2s ago
Process: 11703 ExecStart=/usr/lib/security-misc/hide-hardware-info (code=exited, status=0/SUCCESS)
Main PID: 11703 (code=exited, status=0/SUCCESS)
Jul 09 13:58:07 parrot systemd: Starting Hide hardware information to unprivileged users…
Jul 09 13:58:08 parrot systemd: hide-hardware-info.service: Succeeded.
Jul 09 13:58:08 parrot systemd: Finished Hide hardware information to unprivileged users.
Could you please read and apply the following?
It says that it succeeds. What’s the issue?
It’s a usability issue: confusing message.
This should help.
Upon reflection, the security impact of this seems far greater than anything related to hardware identifiers.
Therefore this feature shouldn’t be dubbed as
Restrict Hardware Information to Root but
Reduce Kernel Information Leaks?
I could rename the systemd unit and keep an systemd
Alias= for legacy compatibility.
Due to today’s discussion on telegram, I’ve just now updated the documentation of this feature to clarify what it can do and what it cannot do.
Yes, that’d be a good idea.
This was done:
Reduce Kernel Information Leaks
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)
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.
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 184.108.40.206 on kvm and version 220.127.116.11 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
This needs some documentation how to test this: