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
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 Protocol Leak 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
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. 
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