´sudo´ does have the advantage that, for example, you can log into a box via ssh as an individual user and then use sudo. It helps with logging who did what, at least assuming the user is not actively deleting logs.

It's true, it avoids typo rm /* instead of ls /*.

simple sudo protection: you leave your workstation and the shell is open, if you su'd before you have a root shell directly at hand, if you used sudo in the morning that person only has a user shell. Sure they can deploy that escalation script, but then they need to come back later again for a second attack and do whatever they wanted to do as root. Or they need their script to send the user password around. A user password that might be easier to change (affects only one person) than the root password (might be shared among several admins).

it seems this answer has a binary view, i.e. it seems to assume no full road-block means no use as a road block at all. Even if you just go by "protecting against yourself", it's a security tool because it might prevent you from accidentally running malware that needs root to use its full potential. So as an improvement suggestion: I'd either provide more arguments for it not serving any security purpose, refining what that means to you and/or being more precise in the wording / perhaps adjust the overall stance to "it also/mainly helps you to not mess up your security yourself"

This completely neglects the NOPASSWD flag in the sudoers file. If NOPASSWD is NOT present in /etc/sudoers - as it should not be if you are concerned about security - you will be prompted for your password. Unfortunately, many distributions use NOPASSWD flag by default simply for convenience. This answer also neglects the fact that commands run by sudo are audited (recorded). If your syslog is set up correctly, it will be sent to a remote server and might even (possibly!) get analyzed for abuse. Knowing you are being watched is a strong deterrent to abuse.

No security measure is 100% foolproof. The fact that an exploit exists does not make a security measure invalid; it just means it cannot be implemented alone. In this case, despite the ease of crafting the exploit you presented, it relies on the user interacting with the system to make it viable. For server systems, with automated management in some fashion (e.g. updates via cron job) this may be a significant hurdle to an attacker.

Aside from the issues pointed out by others with this answer, it also ignores the fact that sudo (when not used with the NOPASSWD config flag) provides a reasonable level of protection against casual interlopers. It's not comprehensive security by itself, but it does raise the bar by a bit compared to not having it.

@FrankHopkins you don't need to come back later. Most attackers would likely leave a reverse shell payload to another machine they own. To me it seems that sudo is perceived as a much bigger safety than it actually is (not saying it fully useless of course). I'm not sure which "casual interlopers" wouldn't know ways to escalate this. Even basic pen testing challenges are harder.

@Wernight coming back may be required when the machine is not networked for instance, but at the least they need user interaction and have to wait. To me it seems the focus here is too much on "cannot absolutely secure you against a well-versed attacked". My scenario also holds for the more or at least equally common threat of a disgruntled co worker that just stumbles over your open machine. In the other case, if a professional attacker really needs physical access, the network might well be policed, too and you cannot randomly connect to another machine or not at all.

@Wernight but the main argument is not that you cannot circumvent sudo, it's not meant as a insurmountable wall to absolutely shield your root user - of course, if you have already user level access and the user uses root from time to time, you will be able to compromise the root access too over time. sudo can help to increase the time you have to detect the problem / increases the time the attacker needs to do whatever mischief they want. Potentially by a substantial amount, but yes, if you come prepared you will get around it. If you come with a ladder, you will also climb a wall.

But isn't that a bash vulnerability? BTW, sudo purpose is not to protect you from yourself, it is to execute a command on behalf of another user. Believe it or not, that's very useful and can be used to improve both security (no shared root password) and safety (as you said). But, as a KISS tool, it just does that. There is no way to exploit the real sudo binary (modulo 0days). What you showed seems a bash vulnerability to me, after all the same applies to su. Anyway, you can make the fake sudo execute the user command and the malware. Once root, the latter doesn't need the pwd anymore

"To have a real separation of privileges you should run administration stuff on a totally separate account." This is true, but note that, for this to confer any security benefit at all over using sudo, it's also necessary to never access the administrative account from the non-administrative account. This includes not using su from the non-administrative account. That su asks for the target user's password does not confer further security, since a fake su command is just as easy to make as the fake sudo command shown here.

This seems like a problem with shells and the UNIX ecosystem rather than sudo. Sudo doesn't let you do this, Bash does.

sudo allows an account to perform certain actions at elevated privileges that it would not normally be able to perform. The fact lazy admins regularly deploy systems with all users from any terminal being allowed to run any command is not a problem with sudo. Sudo is therefore only as useless as the admins that depoly it.

@MargaretBloom: You know I could just change .bash_profile to read LD_PRELOAD=~/trojan_libc.so exec ~/alternate_bash right?

@JeffW wait, what's wrong with NOPASSWD in regards to security? When I use command aliases and other aliases to make, say, apt or a particular script available (by absolute path). But it's not even limited to running stuff as root. You can user1 to run a particular job on behalf of user2, for example. Only shame is, there doesn't seem to be a way to hand out capabilities in a fine-grained fashion the way sudo hands out superuser rights.

I feel the question and the answer highlight a missed opportunity of further securing Linux Desktops: They lack a real Secure attention key. Ideally, sudo should ask: "Please press the secure attention key and confirm the execution of the command". Of course, pressing the secure attention key would make some privileged code (e.g., kernel or X) ask "An unprivileged processed asked for 'apt-get install rootkit' to be executed. Allow?"

@0xC0000022L - NOPASSWD itself isn't the problem. The problem is that 90% of the time (and usually 100% of the time when it's used in the distro's default sudo config) it appears as NOPASSWD:ALL. NOPASSWD for specific commands (by absolute path, as you said) isn't necessarily a problem for security. Unrestricted NOPASSWD access to all commands, on the other hand, is a problem.

@DaveSherohman I'm not aware of a distro including NOPASSWD as default. Besides, the part before NOPASSWD:ALL matters quite a lot itself. Allowing some unprivileged user to execute commands as another unprivileged user isn't really a security issue either. But I get what you mean and I also hold that the sudoers file is underused and the respective man page probably not read (and understood) often enough.