Patrick
December 20, 2019, 11:20am
21
I want to add a usability feature.
As user user.
stat -c "%n %a %U %G" /bin/su
/bin/su 755 root root
which su
/bin/su
I.e. su is still executable by user user even though it has suid removed. This is bad because su fails open, i.e. in weird ways. It does not report “missing suid”. What I preferred:
sudo chmod o-x /bin/su
stat -c "%n %a %U %G" /bin/su
/bin/su 754 root root
which su
su
bash: /bin/su: Permission denied
Now user user cannot execute su anymore. It is failing closed.
1 Like
Patrick
December 20, 2019, 11:31am
22
This is the script output as of now.
run: dpkg-statoverride --add --update root root 0755 /home
new_mode is either 755 or 754. I.e. has still execution permission for others or group.
For config entries stating nosuid only: Would it be a good idea to hardcode / change newmode of these to 744? I.e. to remove exeution permission for others and `group?
if [ "$new_mode" = "755" ]; then
new_mode=744
fi
if [ "$new_mode" = "754" ]; then
new_mode=744
fi
if [ "$new_mode" = "745" ]; then
new_mode=744
fi
I guess the question is:
Are there suid or guid binaries which are still useful if suid / guid has been removed from these?
1 Like
Patrick
December 20, 2019, 12:05pm
23
Could you please review if it is sane to remove suid / guid from the following binaries? @madaidan
run: dpkg-statoverride --add --update root root 755 /bin/fusermount
Does the suid default whitelist need to be expanded?
1 Like
Patrick
December 20, 2019, 12:58pm
24
Found some issue.
Dec 20 07:54:47 disp3633 permission-hardening[26043]: + seq -w 000 4777
Need to use a better regex here.
Another issue.
user@disp3633:~$ sudoedit /usr/lib/security-misc/permission-hardening
That is because there is a significant time gap between suid removal from /usr/bin and re-adding the whitelist of /usr/bin/sudo. Therefore we need to implement the whitelist another way. Not by first removing suid and then re-adding. Better to not modify file permissions of sudo (and other white listed ones) at all. Otherwise this can cause a lot bugs which are timing dependent (when other scripts use sudo).
1 Like
Patrick
December 20, 2019, 1:03pm
25
Found some issue.
Dec 20 07:54:47 disp3633 permission-hardening[26043]: + seq -w 000 4777
Need to use a better regex here.
Not perfect but functional.
committed 01:02PM - 20 Dec 19 UTC
no longer use seq due to issue
https://forums.whonix.org/t/permission-hardening… /8655/13
1 Like
Patrick
December 20, 2019, 1:59pm
27
fso: /lib/
Can reproduce manually too.
shopt -s globstar
stat -c “%n %a %U %G” /lib/**
> bash: /usr/bin/stat: Argument list too long
We are hitting ARG_MAX
getconf ARG_MAX
more info:"Argument list too long": Beyond Arguments and Limitations | Linux Journal
How can I prevent arguments to `xargs` from being prefixed with spaces? - Unix & Linux Stack Exchange said xargs can split it up.
Will use
done < <( find "${fso_without_trailing_slash}/" -print0 | xargs -I{} -0 stat -c "%n %a %U %G" {} )
to fix it.
That does not work. It will “forget” to process some files.
find /usr/bin | wc -l
1149
Added a counter.
INFO: fso_to_process: ‘/usr/bin/’ | counter: ‘575’
1 Like
Patrick
December 20, 2019, 2:50pm
29
sudo /usr/lib/security-misc/permission-hardening
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
On Qubes there is also /bin/sudo and /bin/brwap. Fixed.
committed 02:48PM - 20 Dec 19 UTC
1 Like
Patrick
December 20, 2019, 3:28pm
30
Found a way to crazy speed up things. Using find with -perm /u=s,g=s. Will add.
1 Like
It’s fine. Do what you want. You’re better than me at writing bash scripts anyway.
You can just add another rule for su:
/bin/su 0700 root root
What’s the point of reading binaries if it can’t even be executed? Maybe just give a mode of 700.
It’s fine to remove it from most of them but whitelist sudo, virtualbox, polkit, dbus and chromium. Chromium only needs suid if unprivileged user namespaces are disabled which Debian does by default.
1 Like
Btw, I noticed in the script you refer to setgid as “guid”. It’s not “guid” but “sgid”. GUID is different and may cause confusion.
1 Like
Patrick
December 20, 2019, 5:03pm
33
Could you please review if it is sane to remove suid / guid from the following binaries?
It’s fine to remove it from most of them but whitelist sudo, virtualbox, polkit, dbus and chromium. Chromium only needs suid if unprivileged user namespaces are disabled which Debian does by default.
VirtualBox has “plenty”. 6 at the moment.
In future, more/less might be added or paths might change. In that case, I would like to avoid hunting down bugs due to that.
Any reason not to add a nosuid whitelist matching feature? Could match for /virtualbox/.
I don’t see how such a matching feature could be abused. Threat model:
Btw, I noticed in the script you refer to setgid as “guid”. It’s not “guid” but “sgid”. GUID is different and may cause confusion.
Fixed in git master.
1 Like
Are any of these actually used? Is there any breakage from removing their SUID bits? If not, then we can just ignore them.
I doubt VboxNetDHCP would be used seeing as Whonix doesn’t even use DHCP at all.
Would be better to match for /usr/lib/virtualbox/ in case some random directory that just happens to have the name “virtualbox” gets whitelisted.
1 Like
Patrick
December 20, 2019, 5:39pm
35
set-user-id set-group-id found - file_name: ‘/usr/lib/xorg/Xorg.wrap’
Needed?
At first sight looks important. But Debian / systemd might not use / need it.
Are any of these actually used? Is there any breakage from removing their SUID bits? If not, then we can just ignore them.
Not yet tested. Can’t find anything online what these are used for. Testing this can be future work.
I doubt VboxNetDHCP would be used seeing as Whonix doesn’t even use DHCP at all.
security-misc isn’t just used by Whonix. I don’t want to break VirtualBox (hosts) for those who install security-misc or Kicksecure.
Would be better to match for /usr/lib/virtualbox/ in case some random directory that just happens to have the name “virtualbox” gets whitelisted.
Will add.
1 Like
Patrick:
Needed?
No, Debian and many other linux distros use Xorg rootless by default so there’s no need for the suid wrapper unless the user themselves has configured X to run as root for whatever reason (which is a security risk due to X’s large attack surface).
1 Like
We can use this to remove capabilities of some unneeded binaries too by using the none capability rule.
getcap -r / 2>/dev/null
/usr/lib/x86_64-linux-gnu/gstreamer1.0/grstreamer-1.0/gst-ptp-helper = cap_net_bind_service,cap_net_admin+ep
I think we should remove the capabilities of /bin/ping since it doesn’t work with Tor anyway.
1 Like
We can add Whonix specific things such as ping capability removal to anon-apps-config package as a drop- snippet.
Pull requests welcome.
1 Like
Patrick
December 21, 2019, 7:34am
40
This is now in the developers repository. Enabling it will be easy.
sudo systemctl enable permission-hardening.service
It might be enabled by default one day (similar to Restrict Hardware Information to Root - Testers Wanted! ) but it needs a fair amount of testing as I am running into many issues here.
We’ll also need some way to record changes and to undo these.
Breaks whonix-firewall.
Dec 21 06:43:54 host enable-firewall[351]: iptables/1.8.2 Failed to initialize nft: Protocol not supported
1 Like