Restrict hardware information to root

## 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.

2 Likes

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?

Added some minor commits on top. Please check.

2 Likes

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.

Looks good.

2 Likes

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 test -r /proc/cpuinfo part checks if it’s readable. If it isn’t readable, nothing happens.

1 Like

madaidan via Whonix Forum:

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?

Very much so. Empty page created.

1 Like

madaidan via Whonix Forum:

systemd-detect-virt output: /usr/lib/whonixcheck/preparation.bsh: line 79: sudo --non-interactive systemd-detect-virt: command not found

https://github.com/Whonix/whonixcheck/commit/bc021c349b22030062252115d5a618a362c00651

1 Like

Could you review this one please?

1 Like

Nothing obviously bad. Nothing bad for non- SELinux users. Bad for SELinux users? Unknown by me. No plans too look into SELinux at this point.

Merged due to @madaidan’s OK in telegram chat.

SELinux not actually tested by me since not used in Whonix or Kicksecure at this point. Added comments in source code to point at this link:

security-misc: Enhance Miscellaneous Security Settings

1 Like

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.

1 Like