Restrict Hardware Information to Root - Testers Wanted!

CPU information such as in /sys/devices/cpu/.

OK, but CPU information, specifically, is the special case I already mentioned knowing about.

I’m pretty sure that, by default, VirtualBox sets the CPU type identifier inside of the VM to match the CPU type outide of the VM (even if that creates a nonsensical configuration, like a combination of core type and core count that doesn’t correspond to any processor you can actually buy). I definitely know that KVM does that by default.

But you can also configure the hypervisor to try to emulate a specific CPU of your choice, at which point /sys/devices/cpu (and /proc/cpuinfo) should reflect what you told the hypervisor to emulate, rather than the actual hardware. And the hypervisor will at least try to emulate the right instruction set, too (otherwise tons of user programs would bomb). It still can’t do anything about weird timing and errata attacks, but it should keep the contents of /sys from just giving the CPU type away for free.

Do you know of anything that passes through an actual serial number? That’s where things would really get nasty.

1 Like

No, the hypervisor hides serial numbers. This feature is just for other less important hardware info.

1 Like

Here’s a user-mode program that will get the CPU model without opening anything in /proc or /sys and withouth asking the kernel (link munged so the software will let me post it): https: // gist-dot-github-dot-com /9prady9/a5e1e8bdbc9dc58b3349

2 Likes

That makes me feel better, anyhow. :slight_smile:

1 Like

That doesn’t work for me but I imagine it uses the cpuid kernel module which can be fixed by blacklisting it in modprobe.d or unsetting CONFIG_X86_CPUID which hardened-vm-kernel already does.

1 Like

No, it uses the CPUID instruction. It’s not a privileged instruction; the CPU doesn’t think the information is secret in any way. The WIkipedia entry is “CPUID”.

It works for me. I looked at the code and it does indeed seem to be using the instruction, not making any call to the kernel. I ran it under strace and didn’t see it do anything else.

In fact, in the man page for the cpuid kernel module, it says “The CPUID instruction can be directly executed by a program using nline assembler. However this device allows convenient access to all CPUs without changing process affinity”.

2 Likes

Ah, that’s definitely a problem then. Is there any way to hide the output of that without making the hypervisor emulate the CPU?

1 Like

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.

2 Likes

Thanks for telling me about this. I’ll look into it further.

The only thing I can find about this is linux - Fake output of CPUID instruction - Information Security Stack Exchange

Maybe there’s a way to patch KVM on the host to fake the CPUID instruction.

1 Like

The relevant code seems to be linux/arch/x86/kvm/cpuid.c at master · torvalds/linux · GitHub

1 Like

i tested it in the workstation on kvm. indicator is providing the appropriate notifications.

1 Like

Have had the service enabled for the last two days on Qubes-Whonix 15, no problems so far. Everything works properly.

2 Likes

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
Docs: GitHub - Kicksecure/security-misc: Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc
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[1]: Starting Hide hardware information to unprivileged users…
Jul 09 13:58:08 parrot systemd[1]: hide-hardware-info.service: Succeeded.
Jul 09 13:58:08 parrot systemd[1]: Finished Hide hardware information to unprivileged users.

Could you please read and apply the following?

It says that it succeeds. What’s the issue?

1 Like

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.
security-misc: Enhance Miscellaneous Security Settings

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