Re: @Uffe Seerup
sudo whoami, sudo id
That is justthe default behavior!!! BTW, It has nothing to do with the setuid root of sudo! If you're not specifying, who you want to be , sudo thinks it is root, i.e., "sudo whoami"="sudo -u root whoami". From the man sudo:
The -u (user) option causes sudo to run the specified command as a user other than root.
The same goes with su. As well, "su"="su root", "su johnny" !="su" (asks for johnny's password, not root or your own). However, when you run "sudo -u postgres whoami" produces "postgres". Never does it let you be a root or anything else of you ask and what you're allowed to be. Moreover, the default sudoers would usually list the group that is allowed to be a superuser (wheel, admin or sudo).
A setuid tool runs with the owner of the file as the effective user of the process. You may restrict *who* can call sudo in the sudoers file, but you *cannot* change the fact that sudo starts as root.
Okay, than tell us how to effectively exploit this "vulnerability"? A lot of user actions might trigger starting a few root/system processes, say rsyslog, dmesg, kernel events etc Userland and system must communicate somehow. Your misinterpretation of setuid bits and the default options of sudo and su makes you believe your own argument.
If on your system you have two regular users and know passwords for each one you can jump from one user to the other via "su anotheruser". Notice, you never become a root here. If you don't know the root password running su won't let you be root, if root is locked it won't let you be one as well. Similar with sudo, if you are not a member of the group sudo on my Debian machine, but sudoers has this
uffe mydebian = (postgres) /usr/bin/psql
you'll be allowed to run "sudo -u postgres" only on mydebian machine, with your own password and would be able to become superuser of the postgresql database, not the whole system, as far as the psql shell is concerned, nothing else beyond that shell. You won't be able to stop or start the daemon/server of postgresql, nor anything else besides that. It's not "sudo", moreover you can get yourself in trouble, since sudo will tell on you to the administrator, so you gotta run "sudo -l" to see what you can and can't. That would give some statistics for you in the sudo system without the ability to see the complete sudoers file, BTW.
In that case, notice that never did sudo start as root!!!
Here's another example to explain the -s- bits. Consider the at utility of scheduling jobs at specified time (non on the regular basis, otherwise, it is similar to crontab):
ls -l $(which at)
-rwsr-sr-x 1 daemon daemon 55456 Jun 9 2012 /usr/bin/at
As you can see it does have the setuid for daemon, both group and user. However, when you run (as user eulampios):
at 12:00
warning: commands will be executed using /bin/sh
at> /usr/bin/id | /usr/bin/mutt -F /home/eulampios/.mutt/muttrc4 eulampios@localhost
at> <EOT>
You'll get a mail with "uid=1000(eulampios) gid=1000(eulampios)...." not "uid=1(daemon) gid=1(daemon) groups=1(daemon)", like the output "sudo -u daemon" would produce. Despite the daemon setuid and setgid bits, never does it let you be daemon. Is it clear now?
So again, you're confusing the default setup and the setuid bits concept, making baseless conclusions therein.
Proving my point.
And what is your point? MS devised a more secure system than any Linux or Unix ever did. Are you sure? What about all that malware that runs on MS Windows systems without the user's consent (and that is apart from the insecure repository models or the lack of thereof). What about XP, where many user apps could not even run without the admin rights? BTW, the homogeneous approach is always much an easier target than a heterogeneous one. So having many complementary (sometimes overlapping) highly customizable things is better than a single one.