I’m thinking about the case when a user wants to configure mutliple VMs on the same internal LAN and needs to know the IPs so they don’t conflict.
Can you confirm if running ifconfig as root makes this a non issue?
1 Like
Yes, it restricts it to the root user only. Root can view all that information anyway. If not, we’d have a whole load more problems than just needing to know the IPs.
1 Like
I also remember, there was a mitigation program (userspace) for inducing random packet delays on the VM’s NICs to thwart covert attacks that depend on affecting CPU activity that changes traffic on the network in remotely detectable ways.
While it isn’t applied yet, there’s a good chance this restrictions could break it?
1 Like
That’d probably have to be run as root anyway, so likely no.
1 Like
My main concern here is if there is no obvious way this info can be used to exploit the system, then the benefits are overshadowed by the potential of unknown breakage.
While I can’t find clear info on security examples, there is a lot of perf optimization env variables that depend on the compiler being able to detect CPU flags. AVX, SSE and AES are examples. Without detection one would end up with some really slow code.
There are obvious ways this info can be used to exploit the system. For example, CVE-2019-15916, CVE-2017-13307, CVE-2010-4347 etc.
Grsecurity restricted these for a reason. I’ve also spoken with Daniel Micay about sysfs/debugfs before and he says it leaks a lot of information that regular programs shouldn’t have access to.
If compilers need CPU information, they can be part of a whitelist.
1 Like
Possibly Qubes only.
1 Like
Haven’t considered all posts yet.
We’re leaving VM-only territory with Whonix host / Kicksecure.
Package security-misc is neither Whonix nor VM specific.
2 Likes
Merged. 
1 Like
This I know of. I used to enable sysfs restrictions when using Grsec in the past but it broke some stuff. My comment that you’re replying to is talking about /proc/net/dev though - I don’t think it has much to do with sysfs?
2 Likes
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.
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