Comment Poor security design to start with (Score 3, Interesting) 166
sudo is just another example of the giant (intentional) hole in the security barrier that is setuid root.
Just because of poor delegation design to start with, the setuid bit was invented instead of changing the design to a proper fine-grained access control. Instead of having proper access control lists for all resources like e.g. printers or privileges to set the system time or time zone, Dennis Richie though that setuid was such a neat idea the he went and patented it.
setuid root elevates the process itself to the all-powerful root account as the effective user. This means that all existing access control is moot. An audit of the access control setup can never reliably list what a user is allowed to do on a system. The existence of just a single setuid root tool means that you will need to know what that tool can do intentionally or unintentionally because of a bug as in this case.
a setuid "service" is not a real service with a limited and discoverable surface which can be independently secured, like e.g. a proper daemon with which you communicate through interprocess means. It is a process of which a would-be attacker has tremendous control the environment and parameters. To know what a setuid tool can do you need to read the source code and be able to verify that the tool is indeed the correct manifestation of the source code.