I might not be following…
user@disp1376:~$ ls -la /bin/su
-rwsr-xr-x 1 root root 63568 Jan 10 2019 /bin/su
user@disp1376:~$ stat -c %a /bin/su
4755
user@disp1376:~$ sudo dpkg-statoverride --add --update root root 0755 /bin/su
user@disp1376:~$ ls -la /bin/su
-rwxr-xr-x 1 root root 63568 Jan 10 2019 /bin/su
user@disp1376:~$ stat -c %a /bin/su
755
Do you mean you’d preferred to express things things as u-s (“human readable”) rather than octal (for example 755)? I would agree. I don’t like octal at all. I use human readable version whenever possible. Octal does not work well with my brain at all. When I see octal, I always have to double check using chmod calculator, ls and stat and then actually test things to work as expected. If dpkg-statoverride supported human readable, I’d already request to use that in the config file rather than octal.
Not bad.
When /root is owned by user root and group root and using permission “others-all” (o-rwx), then users other than root such as user user cannot read any file inside /root/some-file because the higher level folder (/root) already keeps them out.
What do we need recursion for? For example to remove SUID from all files residing in /bin? First, recursive remove all SUID from /bin. Then re-add SUID for whitelisted (specifically mentioned in config below or in a lexical higher configuration file) binaries?
Would it help if we simplified the config file syntax? Perhaps for recursion for SUID removal, don’t support the full syntax? Have specific variables or a separate config file with folders which are parses in recursive order to remove all SUID?
And then file-by-file (non-recursion) re-adding of SUID could be the existing file format? Maybe no need to express everything in the same config file? Would that help?
Not sure we should create a huge database adding every file? This could slow down things when the script runs (considering we’ll run at boot time) (and might even slow down apt upgrades?). This database could have a lot entries of files which are obsolete after release upgrade. Ever growing database. Maybe when using recursion (therefore mentioned a “special” recursion feature) it would be better to detect only actual SUID binaries and then add these to dpkg-statoverwrite --add --update? stat seems very efficient. A single call.
stat -c "%n %a" /bin/*
Quickly lists all permissions that a folder.
…
/bin/zless 755
/bin/zmore 755
/bin/znew 755
Then we’d just process those files that need it.
I also don’t think we need to recurse some folders that are already handled elsewhere such as /home. It’s mounted with nosuid/nodev anyhow.
((re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security? - #2 by madaidan)