Issue indeed… The essential issue is this…
(You probably know but I am writing this down as reminder to self and everyone else reading.)
sudo getcap /bin/ping
(Capabilities of /bin/ping
already removed.)
sudo apt install --reinstall iputils-ping
sudo getcap /bin/ping
/bin/ping = cap_net_raw+ep
Even if we could, there would a race condition. A time window of vulnerability. Malware with the ability to abuse a capability could use inotifywait
(or some other mechanism (perhaps brute force trying)) to wait until the binary is updated and the capability reinstated.
Perhaps once [1] Multiple Boot Modes for Better Security: an Implementation of Untrusted Root existed, malware lurking under user user
should be deactivated once rebooted into admin mode
. Then malware running under user user
couldn’t exploit the vulnerable time window of the capability briefly being re-introduced. If we go for that, we should probably remove upgrade-nonroot
command. It would still be an incomplete solution until… Even if rebooted into admin mode
, there might be daemons running under for example user www-data
. Once [1] is implemented, probbly when booting into admin mode
only a limited amount of systemd services should be executed.
Nothing really is as great as a proper implementation of dpkg-statoverride
. In case of permissions, dpkg never changes back to the different/original/weaker permissions (won’t re-enable SUID even briefly).
Which kind of configurablity do we need? Can we re-implement these?
We cannot restrict which user can execute the program with higher privileges or what arguments they can use.
Can the output of whoami
or some alternative command be trusted? Or can that be fooled with some LD_PRELOAD trick or something?
Let’s pick livecheck.sh [archive] as an example. The script currently uses sudo --non-interactive /bin/lsblk --noheadings --all --raw --output RO
. This could probably be translated to some capability.
- You’re right. We don’t want all users to have that capability. If output of
whoami
or similar could be trusted, the script itself could check if it’s running under useruser
and exit if not so? - The capability might give access to a lot more than
sudo --non-interactive /bin/lsblk --noheadings --all --raw --output RO
.
Am I re-inventing SUID or sudo
here?
My conclusion for now: An SUID free desktop system (including free of sudo
) is impractical.
Now on a second thought… Perhaps livecheck.sh
could be implemented in a more sophisticated way. A systemd unit running as root [2] could run sblk --noheadings --all --raw --output RO
, then write the output to a world readable file. [3] livecheck.sh
could then read from that file instead of running a command with SUID (meaning sudo
).
Perhaps similar solutions could be invented for other cases currently dependent on a /etc/sudoers.d
exception.
We should add support for basic bash/AppArmor-style regex so we can, for example, shorten:
Seems difficult. I would not know how to implement this without over complicating the code. I don’t think many people will read that config, let alone edit it or view the logs.
Currently config doesn’t even support white spaces in folder names. (Untested.) Such as basic feature should be implemented before going fancy with bash/AppArmor-style regex?
Config parsing, the script looks complex enough already for my taste.
Also, do directories like
/usr/local/usr/bin/
even exist?
/usr/local
seems to hold anything that also the root /
could hold. I found mentions of all newly added entries on Google when putting the serach term into quotes such as.
“/usr/local/usr/bin/”
Also for consistency, thought good to add. At worst in costs a second or so and a log entry.
[2] Or limited user with sudoers exception or capability? Too complex, fancy?
[3] Or only user user
? Too complex, fancy?