Sudo give an illusion of security while in fact in many common configurations it is erasing security at several levels. It is as bad as attempting security by obscurity, and in examples where "sudo wget" is possible it is no worse than doing "chmod -R 777 /" -- literally. It is a general over-arching solution to a set of problems which must _never_ have a general over-arching solution in exactly the same way that "chmod -R 777 /" is (and you might be surprised at just how many times I've seen people solve permissions problems with the latter). You really want everyone to have to type a password (or use some other explicitly manual and intentional authenticator) every time they access a root shell. Anything less is effectively increasing the attack surface to include all parts of the user’s account and/or additional devices. If you give someone any automated way to increase their privileges (without extremely careful control over what they can do with those increased privileges), then their account (and any additional systems it can be accessed from) essentially becomes the privileged account, with only a single action with no additional authentication is required to raise privileges. Also, there is little weight to the (false dichotomy?) argument that using a root shell is "dangerous". That argument conflates the idea of using a root shell with the out-dated idea that doing so requires logging in as root, and-or doing everything as root. Novice system administrators should be taught to never use privileged commands of any kind unless the task requires privileges, _and_ they actually understand why the task requires privileges. Inexperienced users will often use extra privileges to work around other bugs in their system's configuration (or design) (and whether they use "sudo" or "chmod" to do such work-arounds is basically irrelevant). Sudo was invented by someone who clearly did _not_ understand the unix security model (and especially not its wider implications and the responsibilities that it requires of a security toolsmith) and it is based primarily on the fallacy that it is somehow possible to give general, configurable, but supposedly limited, privileged access to some commands. On any system where an authorised "sudoer" can successfully run "sudo wget" (or any number of other similarly complex tools) shows perfectly how sudo is almost always abused with no attempt being made to configure it in a sufficiently secure manner. You might be surprised at just how easy it is to get a full root access and a root shell with even the most limited sudo configuration. Even just root access to "cat" would give an attacker a _huge_ massive advantage, especially to any attacker prepared to take advantage of such a situation. The fact that in most setups every user permitted to run "sudo" is now as valuable a target as the "root" account is proof enough. (Though even with plain "su", any any admin's regular user account can still be a very valuable target, and usually gives direct "root" access in two relatively simple steps instead of just one trivial step.) I've never _had_ to login as "root", except on the console of a virgin install. You can't login as root anywhere but on a physically secure server console on any system I've ever managed. Yet I've _never_ installed sudo. Sudo would be OK if it _always_ required a user-specific password distinct from the user's own password (and distinct from the root password), _and_ if it could only be used to execute the very few commands which were truly known to have few or no vulnerabilities and which can not be gateways to shell access. Only at that point would you have something which would be no better than plain "su" (though even plain "su" can be very easily, trivially!, be configured to require distinct "root" passwords for every admin). I.e. it is very easy to create multiple root accounts, each with a user-specific password. I should have mentioned that, but I thought it was obvious. Some could then also be given a restricted shell or single command to run. So, just use "su"! Of course a very restricted automated way of giving temporary privilege is best for specific tasks, but of course there’s a lot more effort involved to make sure it really is safe and secure and that there are still the necessary AAA attributes. Sudo can do this to some extent, even including requiring additional authentication, but it is also far more powerful and far more complex to configure correctly and all too often it is mis-configured or intentionally configured to avoid the additional authentication step; and when you really think about it, "su" (perhaps with a wrapper script and additional account to direct its actions) is already exactly enough for these purposes. So, just use "su"! There have been at least 18 serious security bugs in sudo itself. Sudo's bugs and internal vulnerabilities are _not_ like those of almost any other tool, including SSH. This is due to the fact that it has a complex configuration feature. Even experienced and knowledgeable users can trivially configure it to be a barn without any doors to close. As for the number of possible remaining bugs in sudo, a line count of its source, as compared to a line count of the source to plain "su", should be proof enough of how much more risky it is. If that's not enough we can also note that it supports dynamic loading of plugin code, something that has absolutely no business anywhere near a central part of a security system (outside of Multics, that is). Furthermore the code plays tricks with homegrown memory allocation, packing together various structs and strings into a single allocation -- a stupid economy. System security is hard. Sudo is not a valid solution to any system security problem -- it's a quick and easy hack that reduces system security almost as much as "chmod -R 777 /".