[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Disable SUID Binaries

dpkg-statoverride --list has only limited usefulness for this since Debian itself uses these. There is no way to distinguish which were added by Debian and which by permission hardening.

This is done. https://www.whonix.org/wiki/Security-misc documents how to enable this feature, how to view what was changed and how to undo and disable this feature.

1 Like

It didn’t break those when I tested it and I have no idea why it would break those. Are you sure this isn’t something else?

AppArmor and whonix-firewall run as root anyway.

1 Like
sudo setcap -r /bin/ping ; echo $?

Failed to set capabilities on file `/bin/ping’ (No data available)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
1

1 Like

Weird. It works fine for me.

The only way I can reproduce this is by making /bin/ping suid first. Is your /bin/ping suid?

1 Like

No.

sudo stat -c "%n %a %U %G" /bin/ping

/bin/ping 755 root root

sudo setcap -r /bin/ping ; echo $?

Failed to set capabilities on file `/bin/ping’ (No data available)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
1

But capabilities (was there before) are removed.

sudo getcap /bin/ping ; echo $?

0

The problem is the error message and non-zero exit code. Output could be redirected to /dev/null and non-zero exit could code be ignored but that would break error checking.

1 Like

Any reason to whitelist /lib/dbus-1.0/dbus-daemon-launch-helper?

existing mode:

root messagebus 4754 /lib/dbus-1.0/dbus-daemon-launch-helper


We don’t want to break dbus.

1 Like

I’ve documented SUID / SGID that we will be breaking by default when permission hardening gets enabled:

https://www.whonix.org/wiki/Security-misc#Issues

1 Like
1 Like
1 Like

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.

1 Like

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+ep

I 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:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502580

1 Like

Only 2 things have capabilities by default anyway so that’s not really needed.

1 Like
1 Like

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 + root | persistent + noroot | live + root | live + noroot

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.

1 Like

Should it do that anyway? The point of those options are for whitelisting, not adding back permissions. This doesn’t seem needed.

1 Like
./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 https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information
open dir error: No such file or directory

To fix:

sudo chmod +sx /bin/fusermount
1 Like
1 Like

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.

1 Like

Did that. And probably found the cause:

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]