Is `sudo` almost useless?

Question

Once an attacker has a shell as your sudoer user (or just compromised a local process enough), he/she can use one of the many privilege escalation tool to even automatically put themselves for example as apt or some other processed called by root to gain root access (see also What can an attacker do in this scenario? (unwritable bashrc, profile, etc.)).

What's the point of sudo then outside of blocking smaller payloads or making it a bit harder? It seems that the focus should be on SELinux and such.

Edit: There are 2 side of this question (I should have been more specific). First, what I initially meant, for a standard Linux desktop user. A pretty different answer could be given for a machine administered by someone else.

Answer 1

Sudo has no real security purpose against a malicious third-party. So yes, it is basically useless for that purpose. In the past I believed it was actually a security control to prevent escalation of privilege and make attacks harder, because some people keep on insisting it also has that purpose, but that's actually false. In fact, at the moment you only got one answer to your question, and that answer is propagating that myth. The only purpose of sudo is to protect you from yourself, that is, to avoid messing up your system by mistake. Gaining all the privileges with one click or one key press might be dangerous, while sudo will at least force you to consciously type your password. And if you (or a program or script) ends up touching system files or other users' files by mistake, without consciously using sudo, you will get a "permission denied" notice. So in the end it's just an administration tool, and not actually a security control meant to protect you from an attack.

Here's a very basic example of why sudo offers no real protection against malicious code:

# Create payload: replace sudo with an alias
payload='
    fake_sudo() {
        # Simulate a sudo prompt
        echo -n "[sudo] password for ${USER}: "
        read -s password
        echo
        # Run your command so you are happy
        echo "$password" | sudo -S "$@"
        # Do my evil stuff with your password
        echo "Done with your command, now I could use $password to do what I want"
    }
    alias sudo=fake_sudo
'

# Write the payload to the bashrc config file
echo "$payload" >> ~/.bashrc

That is a very basic example of code that an attacker could run on your machine. It's not perfect, it doesn't even handle every case (it won't work well if you enter the wrong password), but it just shows you that sudo can be replaced by an attacker. If you run that script, the next time you open your terminal and run sudo you will actually be running fake_sudo. An attacker can replace your programs with aliases, or replace the binary files (putting malicious versions in ~/bin or wherever they can be executed in your path), etc.

This is not even a real "escalation of privilege", because a user that can run sudo to become root already has the all the privileges. A real unprivileged user should not have sudo capabilities. To have a real separation of privileges you should run administration stuff on a totally separate account.

Answer 2

I am the co-author of sudo. It was written in the early 80's specifically to address a need to protect the integrity of a shared resource (A VAX-11/750 running BSD UNIX) from its users (the faculty of the CS Department at SUNY/Buffalo). At the time, the only other option was 'su' which required everyone share a single password. Had a calamity occurred it would have been difficult or impossible to sift through the forensics and determine who the fat-fingered perpetrator was...

I think sudo's apparent lasting utility is that it reminds the command line user that they are about to do something which might merit some certainty in the outcome before typing. Granted, in some implementations, like the major raspberry pi distros, where no password is prompted for, it serves merely as a rubber stamp. So go figure.

I still believe that best practices for implementing applications under UNIX-derived operating systems dictate that you run them under a non-root ID. If you need root it should be under controlled circumstances. Think of sudo as the way root access is granted to command line users under controlled circumstances.. That's all.

Answer 3

No, sudo is not useless.

As a user (target)

Usually, when you're on Linux, you're acting as a non-root user. A lot of things, like installing packages with apt, need root/sudo permission to be used. The sudo binary is there to give the normal user permissions to use root level actions like apt install.

You should not be using Linux all the time as root. This is because if you're compromised, the attacker would have root access to your system, which means they can do pretty much anything on your system. Instead, you run Linux as a non-root user, so that even if your account gets compromised, the attacker can't immediately get root access.

Of course, no system is totally secure and something somewhere in your system can be exploited. Using a sudoers account instead of root is one step in securing your system, as discussed above.

If you're saying "The hacker will get in and get root anyway, why should I use sudo at all?", that's like saying "If someone gets in my house, they will be able to (somehow) get my jewellery anyway. Why should I use a safe or locks?". It's an extra layer of protection. We're not looking for "a lock that can protect everything", but "many locks to provide extra security in case a few of them break".

sudo is a safeguard. It allows you to run root-level programs only when you need to. It's so you only sometimes open the door to your TOP SECRET room instead of always leaving it open, even if having it always open (always running as root) is more convenient.

Also, when you're a legit user, you don't run privilege escalation scripts every time you wanna use a sudo action, you use sudo.

As an attacker

The sudo binary can be exploited to gain some information or even get root access. Sometimes, the user(s) may have in their sudoers file something like MY_USER ALL=(ALL) NOPASSWD: ALL, in which case, if you can get access as the user MY_USER, you can run any and all sudo/root commands without passwords. Running sudo -l may also give you information like what commands you can run as root even without a password. An example of such misconfiguration would be USERNAME ALL=(ALL) NOPASSWD: /bin/vi which allows you to run vi as root without a password as the user USERNAME. This is one way to manually escalate privileges.

Every extra program may present some extra vulnerabilities. Having tomcat running would introduce the system to tomcat exploits. sudo may just be another program you can use in your exploitation.

Also, how do you think those handy privilege escalation scripts/tools get you root access? A lot of them use sudo one way or another.

Answer 4

Sudo is far from being useless.

An admin can assign privileges flexibly and granularly and have accountability options (decent logging). It's a significantly better solution to using groups.

Naturally if you compare it to SELinux, the performance and capability of sudo eclipses, though at a massive cost of implementing and configuring (and maintaining).

Conversely from the point of view of an attacker, they may get lucky and capture an account with sudo privileges or take advantage of misconfigurations. Still the amount of effort to escalate from a standard user with sudo privileges to root could be significant. On the other hand, neither of these issues are caused by sudo itself.

Its effectiveness however is entirely dependent on the configuration. It is trivial to privesc a host if a compromised standard account is allowed to run anything as root with no password, it is more difficult but quite doable if it is allowed to run certain commands that can be manipulated and quite difficult if only carefully chosen binaries and situations are allowed to be executed as root.

Also sudo can be used to enable running commands as users other than root, so that's another way to use sudo that may not lead into full system compromise.

Answer 5

sudo is as secure, or insecure, as its popular alternatives like su.

The most popular alternative to sudo is to allow some or all users to elevate their privileges with su. Most commonly, all users are permitted to do so, so long as they know the target user's password. Unlike with sudo, which is nearly always set up to require a user's own password (and is restricted only to users who are trusted), su requires the password of the target user.

Some people assume this makes su more secure than sudo, but it does not. su is subject to the same kinds of attacks as sudo. Suppose you are a user who sometimes runs su to become root. Suppose further that an attacker who doesn't know root's password and cannot yet perform actions as the root user nonetheless manages to execute arbitrary code as your non-root account. Just as this attacker can make it so that when you run sudo you're running their malicious command, so too can this attacker make it so that when you run su you're running their malicious command.

That is, the technique in reed's answer works just as well to introduce a fake su command that captures the password of the target user (which, when su is used to administer the system, is usually root).

But it's possible to do better than either, or to mitigate the risk.

Once someone can run any commands as you, they can usually make arbitrary changes to the way your shell behaves, and thus create fake sudo, su, doas, or any other privilege elevation commands.

However, so long as you can avoid interacting with a fake login screen, you can mitigate this by having separate administrative and non-administrative user accounts. This doesn't sound like a new idea, and of course it isn't, but it's surprising how rarely this is truly done.

Your administrative account could just be the root account. But if you want the benefits of not logging in as root, which include logging (in order to figure out what went wrong in cases of non-malicious mistakes) and the ability to run programs that aren't meant to run as root (most graphical interfaces), then you can have two non-root accounts, one of which is used for administration (in which you run sudo or su as necessary), and the other of which is not.

This account should if course not share access credentials with the non-administrative account. They should not have identical or similar passwords, and they should have separate key pairs. Furthermore, you must not elevate from the non-administrative account to the administrative account, for the same reason you must not elevate from the non-administrative account to root.

If you do that, there is even an argument for sudo over its alternatives.

In this setup, there is a benefit of sudo over su, though it's not a decisive benefit. You can avoid accidentally using the wrong account--the one that is used for all sorts of other non-administrative stuff that may expose it to greater risk--to administer the system, by making it so that it's just a regular limited user account that is not listed, and is not a member of any group listed, in the /etc/sudoers file.

But you can also achieve this goal with su either by exercising proper self-discipline and making sure you're never su-ing from the account you've designed as non-administrative, or by preventing accounts designated as non-administrative from elevating privileges with su. (One way to achieve that, on a GNU/Linux system, is with AppArmor, which is how Ubuntu prevented the guest account from ever using su successfully--back in releases of Ubuntu that used to ship with guest accounts enabled.)

The risk of using sudo or su in the usual way may be acceptable to you.

With all that said, that I'm not saying you necessarily need to do this. It's up to you or, where applicable, up to you and other stakeholders.

For many people, the risks associated with using the same account to (a) elevate to root with sudo (or similar mechanisms like Polkit) or su (or similar mechanisms like doas) as is used for (b) non-administrative tasks like running a web browser may be an acceptable tradeoff for convenience.

Answer 6

The point of sudo is not to make it hard to elevate privileges. It is, in fact, the exact opposite: the point is to make it easy to elevate privileges.

By making it easy to elevate privileges when you need them, users have less of an incentive to run with elevated privileges always.

If you make it hard to elevate privileges, users will just log in as root all the time. By making it easy to elevate privileges "on-the-fly", users are encouraged to log in as unprivileged users and only elevate privileges for a single process for the duration of that process, instead of running with elevated privileges all the time.

sudo is, fundamentally, a usability tool, not a security tool. The security effects of sudo are second-order consequences of the usability effects. Security is not useful when it is not useable.

In this, sudo is roughly equivalent to UAC in Windows Vista+, which is also often misunderstood as a tool for preventing privilege elevation, when in fact it is a tool for making privilege elevation easier. Prior to the introduction of UAC, it was completely normal for Windows users to always log into an account with administrative privileges, simply because for anything but basic office use, Windows was unusable otherwise.

There is an additional advantage to sudo over su or logging in as root, which is that sudo can be configured to leave an audit trail of which user issued which privileged command at which time.

Answer 7

Like everything in information security, sudo is a trade-off.

Let's explore the alternatives:

• changing the system so the commands you use sudo for don't require root-level privileges
• logging in as root to gain those required access rights
• using su to switch to a root shell
• having the command itself run as root, no matter who executes it

without going into the details, I hope you'll agree that all of those alternatives are worse than sudo. It isn't perfect, it can be attacked - but it is the best among those alternatives.

Regarding SELinux, don't forget that it entered the show relatively late. I can't remember which year (and heck, I was there, my name is in the SELinux credentials), but sudo pre-dates SELinux considerably.

And while SELinux is no doubt the more powerful and more secure alternative, most sysadmins aren't able to write a proper SELinux security policy.

So, everything considered, among a bunch of pretty bad choices, sudo is in many cases the least bad one. It's better than nothing or its alternatives, and that's good enough reason. No security is perfect anyway.

---

all that said, the main use for sudo in the enterprise isn't security but accountability. If admins must log in with a personal account and then use sudo for their daily work, it is trivial to track who did what. And using auditd you can keep tracking them when they use su as well.

Answer 8

This depends on how you configure sudo:

On a machine used by different persons, you can configure sudo in a way that certain users can access certain commands using sudo:

You may configure sudo in a way that some user can execute a certain command (e.g. ip) using sudo - but not any other command.

The other thing is that sudo should be configured in a way that you are asked for a password. Even if an attacker has access to a console, he would be asked for your password if he types sudo example command.

You may also configure sudo in a way that certain commands (e.g. ip) do not require a password and all other commands require typing your passwort.

And it is also possible to configure sudo in a way that the password required for sudo differs from your log-in password.

In this case even your log-in password will not help the attacker...

However, if you configure sudo in a way that you can execute all commands and you will not be asked for a password, then sudo does not provide any security.

Answer 9

Most anything without a Secure Attention Key is `almost useless'.

Reed gives an excellent answer as to why sudo (or at least its password feature) is almost useless for security. However, is not just a bug in sudo, bash or even the entire Unix Environment. It is a general problem with getting higher privileges using a password without some technique to avoid fake login prompts.

To start with zsh, fish and even the windows command prompt allow you to customise which command is run, so switching to a different shell won't stop an attacker for substituting fake_sudo for sudo.

This isn't just the Unix Environment. Imagine in say Windows, you go to Start>Change Profile and type in the admin password. Opps, an attacker has replaced Explorer.exe with fake_Explorer.exe, that wasn't the real Start button you pressed. Again the attacker has your admin password.

For these purposes a Secure Attention Key is sometimes used. You may have sometimes seen a Windows login screen saying "Press Ctrl-Alt-Del" to login. This is because Ctrl-Alt-Del goes straight to the OS and cannot be faked by a fake login shell. Because Ctrl-Alt-Del can be used to securely get the attention of the operating system, it is called a Secure Attention Key.

There are some alternatives to a Secure Attention Key. For example, you could choose an image you expect to see when you log in. Better not store that image where unprivileged processes can read it or display it where unprivileged processes can screenshot it though. So this still requires separating out the login screen from the unprivileged general work account in a way tools like sudo don't.

Answer 10

Something no has mentioned thus far is sudo (via PAM) can use other mechanisms than a password and/or use 2-factor auth. Whilst this does not solve the compromised account issue, this does make it harder to fake a prompt.

Additionally, sudo has its uses outside simply giving full root access, it can be use to allow a specific user to run a specific command, and no other as root, or even as another user. I'm not sure SELinux would be as easy to configure for that usecase.

Answer 11

I had the issue once of logging into my server via SSH keys and forgetting my password to use with sudo which suggests this idea:

I suppose that if there are compromised SSH credentials, say recovered from an unwiped hard drive in a rubbish tip then sudo may help as a password is needed to do administrator functions. I have no evidence but I suspect many SSH keys have no password to them.

A more realistic attack vector with this sudo issue are SSH keys left on Github.