Alternatively, could we identify suid binaries and then run chmod o-x [0] on them. I.e. o (“others”) (i.e. user user) may not execute them. In result only root could execute suid binaries but non-root could not. Would that help to reduce the risk of suid binaries?
Tested. It’s possible to remove executable permission for binaries for others (user user) while root can still execute the binary.
Either,
- chmod all suid binaries except a whitelist [1], OR
- we manually maintain a blacklist of suid binaries (the ones shipped by default but we want to disable). [2]
That would prevent non-root users from executing suid binaries.
A dpkg hook or something could re-apply these changes on upgrades. But not great since malware could wait for the upgrade to happen and there would a vulnerable time window between package upgrade and suid re-disable.
Maybe ACL or something similar could enforce keeping the file permissions (chmod o-x) during upgrades?
[0] Or chmod og-x or chmod o-rx or chmod og-rwx or something?
[1] In a noroot boot mode, even sudo could be set to chmod o-x since during such sessions the user decided to trade sudo not being accessible for better security.
[2] On top, there could be a tool to search and warn against newly installed suid binaries.