Oh, I thought you were talking about the sysfs and other hardware info restrictions since later in the comment you were talking about how restricting CPU info could break some compiler features.
There are no ways /proc/net/dev can be used to exploit the system (that I know of), it’s just where lshw gets networking info from (you can check it with strace).
/proc/net in general though does hold a lot of information about the device’s network state that Google thought is too dangerous to allow ordinary apps access to.
I’m not saying this is some really important thing we should restrict. I’m just giving suggestions that we can research further into.
It makes /sys and /proc/cpuinfo owned by the sysfs or cpuinfo groups. The whitelist can be disabled through /etc/hide-hardware-info.d (in case a user doesn’t want anything unprivileged to access /sys or /proc/cpuinfo regardless of breakage). user@.service runs under the sysfs group so it has access to /sys which fixes XFCE.
The main issue now is that there are some directories in /sys which permissions cannot be changed. This causes chgrp to give an error which makes systemd say the service has failed (even though everything has succeeded). This doesn’t really affect anything important but it can be confusing.
Also, kinda unrelated but, would it be a good idea to make a security-misc wiki page instead of using the workstation hardening pages for this stuff? Non-Whonix security-misc users might think those steps apply to Whonix only and won’t apply them.
whonixcheck is failing again even with hide-hardware-info.service disabled. I’m using the developers repository.
[ERROR] [whonixcheck] Virtualizer detection failed. You might be running a virtualizer unsupported by Whonix developers! Whonixcheck aborted!
This might endanger your anonymity. Do not proceed unless you know what you are doing.
Recommended action:
- Shut down.
- Contact Whonix developers.
Debugging information:
Running sudo --non-interactive systemd-detect-virt failed!
qubes_detected: false
systemd-detect-virt output: /usr/lib/whonixcheck/preparation.bsh: line 79: sudo --non-interactive systemd-detect-virt: command not found
I’m using Virtualbox so it isn’t an unsupported hypervisor.
## which makes
## systemd say the service has failed even though
## everything has completed successfully. So, this
## returns "0" instead which makes systemd say the
## service has succeeded.
This happens a lot. This also makes scripts fail which have set -e or an error trap set. Non-zero exit codes happen. A way to solve it is using || true. Will simplify the code.
Since /lib/systemd/system/hide-hardware-info.service uses DefaultDependencies=no should it also use systemd config option RequiresMountsFor to make sure /proc/cpuinfo /proc/bus /proc/scsi /sys is available?
I don’t see how there will be race conditions. chmod doesn’t change the group permissions.
I did use --recursive originally for chmod but removed it due to the errors in /sys but since that’s fixed now, it can added back although there probably isn’t much benefit since if /sys isn’t accessible, neither are its subdirectories.
The chgrp command is already recursive (that’s the -R flag) since the group needs access to subdirectories.
Thanks. I didn’t know this could be done.
/proc/cpuinfo, /proc/bus and /proc/scsi aren’t mount points (only /proc is). /proc/scsi also isn’t available on debian so it will fail.
The script already sorts this out by checking if they exist and if not gives an error. It doesn’t exit the script though so the error might go unnoticed.
Use sudo if /proc/cpuinfo isn't readable in the start-tor-browser script SSE2
Doesn’t look like it. Still seeing this.
if test -r /proc/cpuinfo && ! grep -q '^flags\s*:.* sse2' /proc/cpuinfo; then
complain "Tor Browser requires a CPU with SSE2 support. Exiting."
exit 1
fi
The opposite. I don’t see any significant attack surface exposed by this and it is necessary for SELinux to properly function. Grsecurity had also whitelisted it from their equivalent feature.