> If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming s

> If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries). I read this sentence several times, and I don't know what you mean. Some of the files in /usr/sbin are setuid-root (which, frankly, makes no sense -- traditionally, /usr/sbin isn't in non-root users' PATHs), but most are just plain executable files. The mere presence of those files in a place where non-root users could execute them is not an attack surface at all. They're just a bunch of bytes until someone executes them, and even then, executing them conveys no privilege that the caller of execve() didn't already have. (Unless you're running something like SELinux, in which case it's the job of whoever wrote the policy to make sure that the labels are appropriate.)