Restrict hardware information to root

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.

2 Likes

That was just answering Patrick’s question.

Alright thanks for confirming.

Looks to me like part of their privacy charade.

1 Like

It definitely isn’t a charade, It was picked up from past GrapheneOS work Android Q privacy features in the context of the AndroidHardening / GrapheneOS work · GitHub

2 Likes

The Tor Browser issue is fixed in master now.

https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_31968&id=6cf4e6eabc5eb559baf9721a3caf0544b7480093

If /proc/cpuinfo isn’t readable, it now assumes SSE2 support is available.

2 Likes

Awesome!

1 Like

I’m working on a whitelist here

https://github.com/madaidan/security-misc/tree/whitelist

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.

1 Like

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.

1 Like

I also edited the wiki page to reflect these changes.

Whonix-Workstation Security Hardening: Difference between revisions - Whonix

1 Like
chmod o-rwx "${whitelist_path}"
chgrp -fR "${1}" "${whitelist_path}"

Can we swap the order? chgrp first then chmod? Reason: race conditions. Whitelisted group should always be able to access.

chmod o-rwx “${whitelist_path}”

Should --recursive be considered? Dunno.
Did you consider for each chmod or chgrp command if --recursive should be used please?

2 Likes
## 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