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.
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 ...
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.
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.
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?
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?
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.
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?
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.