to allow removing 1 SUID fix, show INFO message if file does not exist during r…
madaidan via Whonix Forum:
What’s the point of reading binaries if it can’t even be executed? Maybe just give a mode of
700
.
Making the minimal change required for security. Keeping things simple.
Making it easier for users to restore to defaults.
madaidan via Whonix Forum:
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
/bin/ping = cap_net_raw+epI think we should remove the capabilities of
/bin/ping
since it doesn’t work with Tor anyway.
Good idea. We already support:
/usr/bin/ nosuid
Should we add another feature
/ nocap
?
Or should we just
/usr/lib/x86_64-linux-gnu/gstreamer1.0/grstreamer-1.0/gst-ptp-helper
set to nocap
and consider that good enough?
Capability removal only works until package upgrade since
dpkg-statoverwrite does not support capabilities. Feature request:
Only 2 things have capabilities by default anyway so that’s not really needed.
The only missing feature is: if suid / sgid was already removed during a previous run of the service and the user adds it to exactwhitelist of machwhitelist after that, it will not be re-enabled suid / sgid.
An easy fix would be to tell users “boot into admin mode”, run /usr/lib/security-misc/permission-hardening-undo
and reboot. But this is a bit unsafe if other services are already started. “boot into admin mode” should probably mean “don’t start any services such as web services”? Will discuss in multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode
We could auto-restore permissions for later added whitelist entries since permission before change are recorded in /var/lib/permission-hardening/existing_mode
.
if [ "$mode_from_config" = "exactwhitelist" ]; then
could check /var/lib/permission-hardening/existing_mode
. Same for
if [ "$mode_from_config" = "matchwhitelist" ]; then
But not sure if worth the effort.
Should it do that anyway? The point of those options are for whitelisting, not adding back permissions. This doesn’t seem needed.
./electrum*.AppImage
fuse: failed to exec fusermount: Permission denied
Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See FUSE · AppImage/AppImageKit Wiki · GitHub
for more information
open dir error: No such file or directory
To fix:
sudo chmod +sx /bin/fusermount
Really bad bug disabling sudo. Unexplained. Non-reproducible. Not a full disk issue, plenty of free space.
Dec 29 04:17:11 debian-buster-test permission-hardening[413]: INFO: START parsing config_file: ‘/etc/permission-hardening.d/30_default.conf’
Dec 29 04:17:12 debian-buster-test permission-hardening[413]: /usr/lib/security-misc/permission-hardening: line 255: cannot create temp file for here-document: No such file or directory
Dec 29 04:17:12 debian-buster-test permission-hardening[413]: ERROR: cannot parse line: /usr/bin/sudo exactwhitelist
Probably better to abort processing the config file and immediately exit
with error when that happens. Will implement that.
Did that. And probably found the cause:
Found bug.
/usr/bin/torbrowser: line 252: /bin/mount: Permission denied
/usr/bin/torbrowser: line 270: /bin/mount: Permission denied
/usr/bin/torbrowser (by Whonix developers) uses mount
to check if Tor Browser folder is mounted noexec.
/bin/mount
is SUID by Debian default.
Therefore /bin/mount
makes sense as executable but with SUID removed.
Fixed.
Not an ideal solution. First add /bin/mount
to exactwhitelist
and then below set /bin/mount 745 root root
. A unintuitive config. But good enough for now?
Anyone got time to read?
Needs a call for testers.
Polishing a few things just now.
https://github.com/QubesOS/qubes-issues/issues/2695 has interesting ideas.
Quote Solar Designer (someone that Joanna Rutkowska respects):
Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)
I think there are two security issues with SUID.
A)
As I’ve added to the wiki just nowSome SUID binaries have a history of privilege escalation security vulnerabilities.
.B)
General attack surface such as kernel attack surface.
What SUID Disabler and Permission Hardener
is currently doing is disable as many SUID binaries as reasonable without breaking a Linux desktop operating system. Improving the situation for A)
To however have the full benefit, to do B)
we would have to eliminate all SUID binaries. This might be reasonable and doable for CLI environments such as servers ( also think Kicksecure).
What do you think?
If you agree, I guess the configuration file of SUID Disabler and Permission Hardener
should be split. The whitelist should be in a separate file. Then a system administrator could easily nuke the whitelist. Alternatively or additional perhaps a ignore_whitelist=true
configuration option would be useful? Then we could document this and some users could benefit from a completely SUID free system.
Improved documentation:
- Security-misc: Difference between revisions - Whonix
- SUID Disabler and Permission Hardener: Difference between revisions - Whonix
Moved to dedicated wiki page:
SUID Disabler and Permission Hardener
Attack surface reduction via disabling of SUID-enabled binaries.
Please review.
since there is already `/usr/bin/pkexec exactwhitelist`
More documentation enhancements:
SUID Disabler and Permission Hardener: Difference between revisions - Whonix
Should we add
/opt/ nosuid
/usr/local/opt nosuid
?
Rationale for /opt
is that some manually installed software installs itself to /opt
. Some lesser important functionality might require suid or sgid. The suid/sgid bit might have been accidentally set by a developer. (Or part of legacy install scripts. Useful in past, then forgotten, now obsolete.) Removal of suid / sgid might in many cases go unnoticed by the user. (In cases where that software is run as root anyhow.)
On the other hand, the /opt
folder is empty on a default Debian (based) installation. One could argue if the (super) admin installs files there it should be honored by the system and kept unobstructed.
I guess it depends if (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security? would re-mount /opt
with nosuid
anyhow?
Other folders where suid binaries might end up?
-
/home
?
But adding that I guess would be excessive because:
- Will be covered by (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security? anyhow which will be a better solution.
- Avoid long scan times during boot.
- Requires root anyhow to create root owned suid binaries. System administrator shouldn’t create root owned suid binaries in home folder anyhow.
Also /root
? Depends on outcome of this post SUID Disabler and Permission Hardener - #65 by Patrick - A) vs B).
Others:
-
/mnt
? -
/media
? - Any others?
split `/etc/permission-hardening.d/30_default.conf` into multiple files `/etc/p…
`whitelists_disable_all=true`
since whitelist needs to be defined before SUID removal commands
This reverts commit 36a471ebce883f7a1660977f486b21ece320d0c2.
`whitelists_disable_all=true`