Not exactly the most accurate way but, with hide-hardware-info.service disabled:
lshw | wc -l
151
With hide-hardware-info.service enabled:
lshw | wc -l
36
This hides a considerable amount of hardware information. You can only see the size of memory, some minor scsi information and network interfaces. Even then, this can be restricted further by restricting certain files in /proc and /dev.
Can you patch this upstream? Some code “if not readable, try with sudo --noninteractive”?
I don’t know how to patch TBB upstream so I created a trac ticket Use sudo if /proc/cpuinfo isn't readable in the start-tor-browser script (#31968) · Issues · Legacy / Trac · GitLab
I managed to nail down scsi information to /dev/sg* and network interface information to /proc/net/dev. ip a still shows network interfaces though.
Not sure if restricting /proc/net/dev and /dev/sg* should be part of the main script as it’d probably break a whole load more stuff. Maybe we can add an --extended flag to the script.
lshw now only really shows how much memory I have.
Restricting access to all of /proc/net might be a good idea too.
Maybe hide-network-info.service or something?
How would users pass such a flag? systemd drop-in file seems difficult.
Could be a status file if /etc/something exists, hide more or so.
Easier to have another systemd unit file?
Really cool!
Does hiding CPU capabilities from non-root users break any (compile time) security hardening? @HulaHoop
Is that code even still required nowadays? Would firefox not error out with appropriate error message?
/dev/sg* isn’t network information though.
Could be a drop-in directory that the script sources from like /etc/hide-hardware-info.d.
Dunno. Hard to test since any non-ancient CPU has SSE2 support.
This seems to indicate it does Your hardware is no longer supported | Firefox Help
Perhaps suggest that in the ticket?
Not merged due to your suggestion.
Merged.
Merged.
I’m not sure if the check should be removed.
With the hardware info restrictions, I don’t get any error from TBB after starting it with the checks commented out. Firefox might think the CPU is recent enough if it can’t read /proc/cpuinfo.
Therefore, it’s better for users who don’t have SSE2 support to fail at startup rather than running it without any notifications and having it randomly break.
We’ll need to figure out another way to fix XFCE then. We can start by making a whole bunch of XFCE/Xorg/Dbus related binaries setgid and see if it works.
I guess it would crash before showing any GUI with an error message and not crash randomly during run.
systemd-detect-virt
Failed to check for virtualization: Permission denied
With hide hardware: This broke whonixcheck. Could you add sudoers exception please?
I can’t replicate this. It works fine for me.
The user@1000.service systemd service fails when hide-hardware-info.service is enabled.
This can by fixed by creating a sysfs group, editing the hide-hardware-info script to make /sys owned by the sysfs group and creating the file /lib/systemd/system/user@.service.d/sysfs.conf with the contents:
[Service]
SupplementaryGroups=sysfs
This also fixes XFCE.
The problem with this though is that user@1000.service starts a bunch of processes that now have unrestricted access to /sys. This includes things like gpg, gvfs and pulseaudo.
Running chown root:sysfs -R /sys in the hide-hardware-info script also makes it fail with errors about not being permitted to change the ownership of /sys/kernel/tracing and /sys/fs/cgroup. So those will somehow need to be excluded or we can give the sysfs group only access to commonly accessed files in /sys instead of giving it total access.
Of no value on non mobile/Android devices becuase VMs don’t have IMEIs or a serial number (the only two things mentioned in that doc).
On Linux it does provide harmless info about traffic bytes and throughput when you cat the interface. I have no idea what that might break (yet) but it’s safe to say we don’t gain a whole lot from shutting it down.
It didn’t say anything about IMEIs or serial numbers.
apps cannot access
/proc/net, which includes information about a device’s network state
That post was about specifically /proc/net/dev, not all of /proc/net.
Fair enough though blocking could breaks tools like ifconfig?
/proc/net/dev
This has information about sent and received packages for all interfaces.ifconfiggives a more readable output.
https://raymii.org/s/snippets/Procfs_tips_and_tricks.html#toc_19
It will but that’s really the entire point of it. Restricting access to /proc/net is to hide a bunch of network information from ordinary users. If ifconfig could easily display it anyway, it’d defeat the point of it.