Hardware information masking and spoofing with hypervisor

User Support
1

Feature Request:
I tested on debian, whonix and fedora, about getting hardware info. Seems that whonix has fair performance on hardware information anonimity on while debian and fedora make no efforts on it.
Such information can be acquired by software with or even without root privilege and used to create a unique fingerprint.
I suggest to implement masking and spoofing on hardware info(Model and serial number of CPU, RAM, GPU, HDD, Motherboard, Network Adapter, etc) at virtualizer level.

2 Likes
2

I was always extremely cautious with this especially regarding automated upgrading/updating firmware/drivers for example…

1 Like
3

I think masking at Virtualizer level does not affect driver upgrade.

4

Well, if your sys-net uses drivers for your wifi chip for example, it needs to know what wifi chip it is of course.

But generally i agree on the normal qubes not needing to know serial numbers or even the type of CPU i am using.

5

I might have just what you need (Reduce Kernel Information Leaks):
\ security-misc: Enhance Miscellaneous Security Settings

Basically, use Kicksecure for sensitive templates and enable hide-hardware-info.service.

I’ve been using it for quite some time now for all my templates (morphed a debian-11-minimal with kicksecure-qubes-cli). It’s been working great, no issues so far (except for two very specific use-cases). Only thing, I had to bump the memory of sys qubes up ~200 Mb, and vm boot time is a few seconds slower.

Alternatively, you may try installing the security-misc package directly (you will need the kicksecure repo) and try enabling the service without fully morphing a debian template.

6
7

I just tried exactly this, cloned a deb-11-minimal template, installed security-misc after enabling the kicksecure repo, enabled and started the hide-hardware-info.service and it works as expected. No full morphing necessary.

8

@marmarek marmarek commented on Oct 17, 2018

FWIW we don’t set vendor string there, only select feature bit (SMAP to 0, VMX/SVM are translated to nested_hvm xl.cfg option).
And given the list of XSAs affecting systems with custom CPUID vendor string, I think we shouldn’t do this. If libvirt will support custom vendor string (it doesn’t right now), we already have a mechanism to set that. But such change will not be here by default.

Does this mean it’s not (yet) advisable?

9

I only skimmed the issue on github but my understanding is that the solution I proposed in #5 shouldn’t mess with what’s mentioned in the issue.

From https://github.com/Kicksecure/security-misc:

A systemd service restricts /proc/cpuinfo , /proc/bus , /proc/scsi and /sys to the root user. This hides a lot of hardware identifiers from unprivileged users and increases security as /sys exposes a lot of information that shouldn’t be accessible to unprivileged users. As this will break many things, it is disabled by default and can optionally be enabled by executing systemctl enable hide-hardware-info.service as root.

And to address the last commend in the quote, I haven’t found broken things yet.

With this I’m not endorsing or recommending everyone to install it, I’m just sharing my personal experience with this particular OS and package, which may (or may not!) be helpful to the topic of this thread.

1 Like
10

Well, I guess it would not be a problem if we can choose to mask or not in Qube Settings.

11

Thank you!
But I still believe it’s a feature needed. Any software installed by ourselves can be unstable, incompatible with updates and less production grade. It may also change the software fingerprint of the VM.

12

Certainly, but we’re talking about installing software in a template VM, not in dom0.

Well any piece of software will contribute to that, no matter the source. So unless you only use the default debian-11 (or fedora) template and don’t make any sort of modifications to it, I doubt this will be a concern.

If you want to try it out without having to install anything, you can do so in a whonix-based dispvm as it comes pre-installed. Just enable and start the service there to see if it works out for you, and if it doesn’t you can simply shutdown the disposable vm and no changes will persist.

13

very nice didn’t even know that something like this exist. Would it perhaps be possible that this stuff would be implemented in qubes like an experminetal hyper paranoia setting during installation?

I also believe that there are many other usefully tools like that for example sdmem to delete the password header out of ram. perhaps we should open a topic for the collection of this tools?

thabks

14

It would require template implementation, so I doubt a new template will be made just for this when alternative options already exist…

Check out these system hardening checklists: