[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Restrict Hardware Information to Root - Testers Wanted!

Please test so perhaps this feature can be enabled by default.

Details about your hardware can be used for identification, so Whonix includes the hide-hardware-info.service systemd unit that restricts access to /proc/cpuinfo , /proc/bus , /proc/scsi and /sys to the root user only. This hides most hardware identifiers and increases security as /sys exposes a lot of information that should not be accessible by unprivileged users.

This setting is disabled by default because it might break many applications. It can optionally be enabled by running the following command.

Read more here:

https://www.whonix.org/wiki/Whonix-Workstation_Security_Hardening#Restrict_Hardware_Information_to_Root

2 Likes

Enabled the service but then it dies on boot. Here are the logs:

 hide-hardware-info.service - Hide hardware information to unprivileged users
   Loaded: loaded (/lib/systemd/system/hide-hardware-info.service; enabled; vend
   Active: inactive (dead) since Thu 2019-12-12 18:24:55 UTC; 1min 42s ago
     Docs: https://github.com/Whonix/security-misc
  Process: 371 ExecStart=/usr/lib/security-misc/hide-hardware-info (code=exited,
 Main PID: 371 (code=exited, status=0/SUCCESS)

Dec 12 18:24:54 host systemd[1]: Starting Hide hardware information to unprivile
Dec 12 18:24:55 host systemd[1]: hide-hardware-info.service: Succeeded.
Dec 12 18:24:55 host systemd[1]: Started Hide hardware information to unprivileg
lines 1-10/10 (END)


ec 12 18:25:44 host systemd[1]: Started redirect /run/anon-ws-disable-stacked-tor/127.0.0.1_9150.sock to Whonix-Gateway port 9150.
-- Subject: A start job for unit anon-ws-disable-stacked-tor_autogen__var_run_anon-ws-disable-stacked-tor_127.0.0.1_9150.sock.service h
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit anon-ws-disable-stacked-tor_autogen__var_run_anon-ws-disable-stacked-tor_127.0.0.1_9150.sock.service has finish
-- 
-- The job identifier is 668.
Dec 12 18:25:49 host dbus-daemon[1534]: [session uid=1000 pid=1534] Activating service name='ca.desrt.dconf' requested by ':1.39' (uid=
Dec 12 18:25:49 host dbus-daemon[1534]: [session uid=1000 pid=1534] Successfully activated service 'ca.desrt.dconf'
Dec 12 18:26:34 host sudo[2180]: pam_wheel(sudo:auth): Ignoring access request 'user' for 'user'
Dec 12 18:26:34 host sudo[2181]: pam_exec(sudo:auth): Calling /usr/lib/security-misc/pam-abort-on-locked-password ...
Dec 12 18:26:34 host sudo[2185]: pam_exec(sudo:auth): Calling /usr/lib/security-misc/pam_tally2-info ...
Dec 12 18:26:34 host sudo[2180]: pam_tally2(sudo:auth): user user (1000) tally 1, deny 100
Dec 12 18:26:37 host sudo[2180]:     user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/systemctl status hide-hardware-info.s
Dec 12 18:26:37 host sudo[2180]: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 12 18:26:37 host sudo[2191]: pam_exec(sudo:session): Calling /usr/lib/security-misc/permission-lockdown ...
Dec 12 18:27:07 host sudo[2180]: pam_unix(sudo:session): session closed for user root
Dec 12 18:27:07 host sudo[2202]: pam_exec(sudo:session): Calling /usr/lib/security-misc/permission-lockdown ...
Dec 12 18:27:16 host sudo[2205]:     user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/journalctl -xe
Dec 12 18:27:16 host sudo[2205]: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 12 18:27:16 host sudo[2206]: pam_exec(sudo:session): Calling /usr/lib/security-misc/permission-lockdown ...

~

2 Likes

KVM only issue? Are you sure it’s caused by that and no other thanges?

Did you test this in KVM? @madaidan

Try boot in recovery mode.

https://www.whonix.org/wiki/Recovery#Recovery_Mode

Disable:

sudo systemctl mask hide-hardware-info.service
2 Likes

I can’t reproduce this in KVM.

1 Like

Masking doesn;t seem to help.

I am on 15.0.0.7.1 BTW do I need to update packages?

2 Likes

That doesn’t make sense. If the service is masked, the restrictions cannot be set at boot. The permissions cannot linger from other sessions either as /sys and /proc don’t persist.

It must be something else.

1 Like

HulaHoop via Whonix Forum:

Masking doesn;t seem to help.

I am on 15.0.0.7.1 BTW do I need to update packages?

No. This is already in stable repository.

1 Like

i am able to boot with the service enabled in kvm. however, it appears to be breaking the live mode notification icon. the disk is currently set to read only. however, the live mode indicator is reporting that the disk is not set to read only, and thus providing the warning.

3 Likes

After disabling (sudo systemctl mask hide-hardware-info.service) it will unbreak (“fix”) live mode indicator?

Does hide hide-hardware-info.service break access to /proc/cmdline? @madaidan

That is what livecheck is using.

1 Like

yes. upon disabling hide-hardware-info.service, it returns to normal.

it does not appear to break it. “cat /proc/cmdline” prints the file without needing any elevated privileges.

2 Likes

the problem appears to be related to the above quoted line 11. it needs root privs to execute.

with service enabled, the execution of lsblk returns:

lsblk: failed to access sysfs directory: /sys/dev/block: Permission denied

2 Likes

Great find!

if [ -n “$(lsblk /dev/disk/by-uuid/26ada0c0-1165-4098-884d-aafd2220c2c6 -o RO | grep “1”)” ]; then

Should we run that with sudo then? (And add a /etc/sudoers.d exception for it?)
Or is that futile because that file ought to be restricted by apparmor-profile-everything even for root?

1 Like

No.

Since /sys is restricted to root, /sys/dev/block/ cannot be accessed unprivileged.

It’s safe to assume that everything used to gather hardware info unprivileged will be broken with this.

Yes.

That would break too many things. Currently, it’s restricted to root with apparmor-profile-everything.

1 Like

Not yet tested.

2 Likes

Huh what? This conflicts with my understanding. What genuine hardware information is exposed inside a VM? There shouldn’t be any at all.

Hypervisors will pass through the CPU by default, but surely the right fix for that is for Whonix to disable it in the VM configuration, and force the hypervisor to fake the CPU. And if you don’t do that, it’s probably pretty pointless to hide /proc/cpuinfo because a user mode program can probably detect most of it anyhow. Any hypervisor that can’t hide the actual CPU model is probably unsuitable for use with Whonix, period.

Most (I want to say all) of the stuff in /proc/bus and /proc/scsi should be faked by the hypervisor and not resemble the real hardware… otherwise nothing should work at all. And given that the hypervisor is faking all of the hardware, there shouldn’t be much if anything to find in /sys either.

Nothing inside the VM should be trusted with any of that hardware information, root or not. You might have to leak a tiny bit about the type of hardware, but any ability to recover an actual serial number from anywhere inside the VM, including the kernel itself, is clearly a serious bug.

Or am I utterly confused about something really fundamental here? Is that stuff being exposed through some path I don’t understand?

1 Like

VMs don’t hide all hardware information and it doesn’t hide the CPU model.

See https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection and Restrict hardware information to root

It can’t. I’ve tested it. Those programs will fallback to /sys which is also restricted.

There are tons of hardware, kernel, debug info etc. in /sys. /sys is especially problematic and has been the cause of many infoleaks such as kernel pointer leaks.

AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy can do that assuming no kernel compromise.

1 Like

Also, security-misc isn’t just designed for use in VMs.

1 Like

It can’t. I’ve tested it.

I’m getting more and more confused… how would you test something like that? Do you really mean you know for sure that there is no user-mode code that can infer the model of the physical processor from the available instruction set, or by reading user-mode-accessible configuration and information registers, or by looking for processor errata, or even by doing timing measurements to get stuff like cache organization? That doesn’t seem testable and it doesn’t really even seem plausible.

There are tons of hardware, kernel, debug info etc. in /sys. /sys is especially problematic and has been the cause of many infoleaks such as kernel pointer leaks.

It might help me to understand better if you gave me one or two examples of things that are carried through from the physical hardware into /sys on a VM.

assuming no kernel compromise.

That’s a pretty big assumption, though. I mean, if you trust the whole Linux kernel, do you even need to run in a VM to start with?

1 Like

Oh, and on kernel pointer leaks… yeah… but that’s not a leak of information about the underlying physical host hardware. It seems to me that the whole point of running in a VM is to protect you even when somebody manages to own the kernel. So, yeah, you want to prevent that, but you still want to avoid leaking real identifiers even if you fail to do so.

1 Like

By trying as many ways I can to get hardware information as an unprivileged user.

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

Never said it was. The restrictions on /sys are meant for security as well as hiding identifiers. I was just saying why /sys is especially bad.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]