Device identifiers and sandboxing in Whonix

Development
1

In the book “Practical Linux Forensics, A Guide for Digital Investigators” by Bruce Nikkel (Chapter 7, Page 204) it states that Machine ID is created during system installation and can be used for identifying duplicated systems or tracking installation timestamps.

Does the current Whonix “shared machine-ID” approach really valid for anonymity or is it actually increase the fingerprinting that the system is Whonix and user is using Whonix?

Maybe it could be used to flag Whonix in targeted investigations or fingerprinting?

Tails has a file (config/chroot_local-hooks/99-zzzzzz_reproducible-builds-post-processing) that randomizes the machine-id each boot by emptying /etc/machine-id. This is a technique that works by leveraging systemd’s automatic regeneration, and it appears is largely independent of Tails RAM based system.

I see both arguments for random and shared ID’s and it reminds me of how Tor Browser users share the same fingerprint. There does however exist an argument that a unique and random fingerprint everytime might be beneficial to mitigating fingerprinting. In fact I believe Brave browser, despite their flaws, does this right in this regard. Mind you this is browser fingerprinting not device fingerprinting.

As @jonathanvlan mentioned in the “Anonymize /etc/machine-id” thread about /proc/sys/kernel/random/boot_id I’m wondering if other Identifiers should either be syslinked to /dev/null or sandboxed to prevent access like /sys/devices/virtual/dmi/id/* for example?

^Note: AI did help with some of this info in this table, but I generally think it is correct when it comes to these locations and what role they serve

| File Path                | Role in Identification                                                | Associated Risks                                   |
|--------------------------|-----------------------------------------------------------------------|----------------------------------------------------|
| /sys/class/net/*/address | Provides MAC addresses for network device tracking                    | Facilitates persistent network-based fingerprinting (real MAC address file) |
| /proc/cpuinfo            | Details CPU model, speed, and features                                | Combines with other data for hardware-specific identification |
| /proc/meminfo            | Reveals memory size, type, and usage                                  | Aids in creating unique system memory profiles |
| /etc/machine-id          | Stores a unique system identifier                                     | Enables session correlation and long-term tracking (cloned systems and installation) |
| /sys/devices/* (e.g., USB or PCI details) | Exposes device-specific hardware information         | Aggregates data for comprehensive device fingerprinting |
| /proc/sys/kernel/random/boot_id | Generates a unique ID per boot for session tracking by primarly used as a seed for RNG | Risks session linkage and uptime pattern exposure |

I can see certain hardening or sandboxing of these files could cause issues and conflicts with debugging or maybe making crypto weaker (/proc/cpuinfo and /proc/sys/kernel/random/boot_id).
You can’t hide the CPU info either in a browser fingerprinting sense.

Is there a way for applying a wildcard for all .appimage’s to prevent access to these things?
I’m pretty sure you can create a global flatpak apparmor file that prevents all software installed via flatpak from having access to these (there also is bubblewrap and flatseal).

What are your thoughts on this and what is already mitigated in whonix already?

2
1 Like
3

Here is an example relating to Telegram having access to /sys/devices/virtual/dmi/id/*

I’m not sure what the most common way people install Telegram on Whonix is i.e flatpak etc.

Tor Browser, Thunderbird, and Hexchat apparmor individual repos show they block access to that and /sys/class/net/ and /sys/devices/virtual/dmi/id/*

I checked https://github.com/Kicksecure/apparmor.d repository, and indeed common messaging applications and clients such as Gajim, Dino, qTox, Signal, Mumble, and Jami (jami-gnome) all block access :grin:

Also Telegram via telegram-desktop rules show it blocks access :+1:
So the above example should be covered by whonix unless certain installations methods of Telegram fall under other names?

I did see some missing apparmor profiles for Pidgin and Profanity (XMPP clients) and Jitsi via jitsi-meet and Simplex Chat.

Worth noting Simplex Chat is an AppImage its not in the debian repository.
Back to my other point is it even possible to block access for all *.appimages or would you have to make or ship rules for each individual AppImage by name?

4

That’s a great ticket where the Tails developers are pointing out why this might be difficult/impossible to implement securely.

This is due to:

Quoting 2 Tails developers.

Quote anonym:

Unfortunately, I think this is way beyond the current design goals of Tails (and beyond what we can afford in terms of development and maintenance). Linux (and other modern desktop OSes) is not at all designed with this kind of information compartmentalization or privacy in mind. /sys/devices is not the only such leak, have a look in the other parts of /sys/, and then there’s /proc. Similarly, applications are not generally designed to have access to these restricted, so it will not be straightforward on that front either.

The only reasonable way to approach this seems to me to be what Qubes or Whonix does (i.e. run everything in a virtual machine so only “fake” virtualized hardware is exposed, but these days with hardware acceleration, device passthrough etc quite a bit of the underlying host system can leak into the VM) but even that is not a realistic undertaking for us at the moment.

IMHO our current approach of locking down (with AppArmor policies) the most exposed applications (i.e. the ones exposed to the network) gets us pretty far pretty cheaply and seems like a good compromise for the time being.

Quote intrigeri:

And as a co-author and recent maintainer of this policy upstream, I have to warn ourselves: it will take lots of work.

Most of these rules encode a trade-off between functionality, UX, performance, fingerprinting, and security.

But surely some came up out of a more lazy process (saw a denial in the logs => simply added a rule to allow whatever Firefox was trying to do). In some cases a decent upstream commit message explains the trade-off. Sometimes it does not.

Bold added by me.

And it happened at least once already that a well-intentionned attempt to harden the policy would have resulted in making the crypto weaker; thankfully I spotted that before it got merged.

Finally, in general, to verify what a rule is useful for, one has to check the source code of Firefox and/or libraries it uses.)

So this requires a lot more expertise and/or research.

1 Like