I mean no offense, but I think that this change detracts from both
usability and security. We have to remember why setuid exists in the
first place. It actually enhances security by discouraging the widely
lamented practice of spending too much time as root. It is useless for
us to say that users -shouldn't- do this. If they are inconvenienced,
and they have the ability to, they will. The only realistic way to
prevent workarounds to sidestep 'security' by normal users is to remove
the perceived need to do so.
After all, what is the biggest, gaping security hole in all *nix?
Root. One account that can do basically anything, and which is sadly
has often been required to do much of anything. The whole reason for
setuid is to allow other users to -use- the system without doing this.
From a distro/programmer point of view, it defeats the point to simply
ship things with setuid off. Realistically, either people will simply
enable it again (no gain, but annoyance) or start running lots of stuff
as root (a palpable security loss). The real gain happens when you can
create specialized user/group roles that can accomplish their tasks,
much like the shadow user for reading /etc/shadow on some distributions.
This may one day soon become moot as ACLs and the equivilant of Lids
functionality breaks the monolithic root up into administrative roles.
I see this as inevitable, and long overdue. This is one point where
Windows has us beat right now.
Besides, its unreasonable to assume that, (other than fixing known
holes) you can really secure a system one program at a time. This is a
case where top-down really is the best approach. If you are concerned,
let traceroute be suid, but implement Lids. :)
Just adding more cents,
email@example.com mailing list