It shouldn’t break XFCE startup just because some file in sys is missing.
Sounds good.
1 Like
https://github.com/Whonix/whonixcheck/pull/12
https://github.com/Whonix/anon-meta-packages/pull/21
How would hide-hardware-info.service be disabled by default? Is adding systemctl disable hide-hardware-info.service to debian/security-misc.postinst enough?
1 Like
Major: Could you please add the licensing header to the new files?
Minor: Could you please add --non-interactive after sudo, i.e.
sudo --non-interactive
for the new whonixcheck sudo commands? (I can also add this on top.)
systemd preset could be the correct mechanism for that? Never used myself yet.
systemd.preset(5) — systemd — Debian stretch — Debian Manpages any help?
Debian debhelper fortunately supports systemd preset nowadays. At least a short look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772555 implies so.
systemd-preset is used by a few packages in Debian. To learn the syntax / compare, perhaps have a look at a few of such packages?
Looks like a snippet in in file
/lib/systemd/system-preset/50-security-misc.preset
with contents
disable hide-hardware-info.service
+ licensing header.
1 Like
Just did those.
What’s the point of --non-interactive? sudo already runs without prompting if there’s a sudoers exception.
1 Like
sudo --non-interactive
- Consistency with other use of
sudoin whonixcheck. - It’s in case sudoers exception file is modified by user or in future upgrade. Better to fail instantly and closed rather than having sudo wait forever for a password which will never be entered.
For now whonixcheck sudoers file is fairly stable but in past it got improved, more hardened. In future the way whonixcheck / sudo works may be improved. I was thinking user user should be able to run whonixcheck without sudo since it could show logs which might contain information which a user might not want to see. (Relatively minor since we probably don’t have many users following advice of Safely Use Root Commands) So changes to whonixcheck suoders file in future are possible. In past whonixcheck suoders file was modified by third parties (Qubes-VM-Hardening).
1 Like
Installing dbus-x11 might not be the best way to fix XFCE.
dbus is handled by systemd, and has been for a long time. Don’t use dbus-launch
Restricting /proc/cpuinfo to root breaks the start-tor-browser script. It exits with an error saying “Tor Browser requires a CPU with SSE2 support.”.
In /home/user/.tb/tor-browser/Browser/start-tor-browser there is:
if ! grep -q '^flags\s*:.* sse2' /proc/cpuinfo; then
complain "Tor Browser requires a CPU with SSE2 support. Exiting."
exit 1
fi
There were no other errors after I commented out that piece of code.
We’ll need to somehow patch this to run that code only if hide-hardware-info.service is not enabled or give another sudoers exception.
systemctl is-active would be perfect for this except it only checks if the service is currently active and not if it has already succeeded.
1 Like
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.
1 Like
Can you patch this upstream? Some code “if not readable, try with sudo --noninteractive”?
1 Like
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
1 Like
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.
1 Like
Restricting access to all of /proc/net might be a good idea too.
1 Like
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
1 Like
Is that code even still required nowadays? Would firefox not error out with appropriate error message?
1 Like
1 Like
/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
1 Like
Perhaps suggest that in the ticket?
1 Like
Not merged due to your suggestion.
Merged.
Merged.
1 Like
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.
1 Like
I guess it would crash before showing any GUI with an error message and not crash randomly during run.
1 Like