110

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.

Wernight
  • 1,187
  • 2
  • 8
  • 8
  • 62
    *"... he/she can use one of the many privilege escalation tool ..."* - You seem to assume that these are generic tools which will definitely work on the target system. But these tools rely on unfixed bugs or misconfigurations. They will not work on a properly updated and properly configured system. Basically you are asking if sudo is useless if all systems are broken anyway. But this basic assumption is already wrong. – Steffen Ullrich Jun 08 '20 at 08:26
  • 1
    It's a lot simpler than you think if you're okay to wait a bit; see @reed's example just for one and the linked question for a naive protection against this. Noticing that for corp machines a limited sudoers can provide protection. – Wernight Jun 08 '20 at 18:06
  • 2
    Good point (and good answer) but this assumes that the user calls `sudo` instead of `/usr/bin/sudo`. Granted, most users will do it this way though. – Steffen Ullrich Jun 08 '20 at 19:05
  • Just wanted to say that I'm impressed with the breath of answers here. From sudo in most distro defaults (my initial presumed scope), to sudo power with a (local or remote) separate admin account (so standard user has limited or not sudo); and other many situations described here. – Wernight Jun 08 '20 at 20:44
  • 8
    For what it's worth, sudo can be configured to grant far more granular permissions than just "root access to everything". Most don't use that functionality though. – Ajedi32 Jun 08 '20 at 21:02
  • 1
    @Ajedi : The ops question should be "Is `sudo` almost useless when lazy admins deploy insecure configurations" – mattnz Jun 09 '20 at 01:39
  • In your edit, did you have anything more besides "Firstly"? I was looking for a "Secondly" .. – auspicious99 Jun 09 '20 at 08:25
  • 12
    You only have half a question here. The real question is "Is `sudo` almost useless _compared to what_?". `sudo` is definitely better security-wise than `su`, and either of those is vastly better than just logging in as `root` at all times. Do you have some other means of giving legitimate users access to admin functionality while blocking unauthorized access, other than `su`/`sudo`/root login, which you believe to be better than `sudo`? If not, then it's at least the "least useless" of those three options. – Dave Sherohman Jun 09 '20 at 10:51
  • 30
    Without `sudo` , how would you get someone to make you a sandwich? – Carl Witthoft Jun 09 '20 at 14:44
  • 2
    @Wernight, it seems like you (and many commenters) are assuming a single-user system. In addition to granular permissions, you also get a log of who did what. – Tommy McGuire Jun 09 '20 at 18:53
  • Sudo was the industry’s first attempt at “secure by default” for console users. (All users were “console”, just at a different wire connected to a serial mux) – makerofthings7 Jun 09 '20 at 21:15
  • https://security.stackexchange.com/questions/187502/do-sudo-and-profile-bashrc-enable-trivial-privilege-escalation/187508#187508 is worth a read. – mattnz Jun 10 '20 at 04:16

11 Answers11

180

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.

reed
  • 15,398
  • 6
  • 43
  • 64
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/109111/discussion-on-answer-by-reed-is-sudo-almost-useless). – Rory Alsop Jun 09 '20 at 16:42
  • Invoking `sudo` logs to `/var/log/secure` or `/var/log/auth.log` depending on your system. That tells you who's account messed up your system, or is potentially compromised. Coupled with a properly configured `sudoers` file, a malicious actor cannot delete or modify these logs. If you took it a step further and only permit actions in the `sudoers` file the user needs and nothing else, the potential surface area for an attack is very minimal, even with a `fake_sudo` like demonstrated above. – SnakeDoc Jun 09 '20 at 17:51
  • 2
    @SnakeDoc `sudo` can do this, but most users want `sudo` for the quite different task of authenticating to administer the system. Also, at least in my experience, those who *think* they use `sudo` this way usually don't. To prevent `sudo` users from being able to perform any action (including modifying logs), it's not "a step further" to limit users to a small, carefully curated whitelist in `sudoers`. It's essential. Many, perhaps most commands can be used to escalate privileges. In practice this includes any command that accepts an output filename as an argument (e.g., `nmap`) and many more. – Eliah Kagan Jun 09 '20 at 21:50
  • 9
    @EliahKagan That doesn't make `sudo` useless - it makes a lot of systems improperly configured. Don't blame the tool for the user's mistakes. – SnakeDoc Jun 09 '20 at 23:20
  • This seems to put sudo in the same category as ./executable – candied_orange Jun 10 '20 at 06:05
  • 1
    Doesn't `su` have the same shortcomming? – Rodney Jun 10 '20 at 08:50
  • @Rodney, basically, yes – reed Jun 10 '20 at 08:56
  • 3
    I you give User unrestricted root access then yes, it does not help against an attacker who has hijacked that account, however you can set up sudo much more fine grained than that. With fixed commands (if you are careful about environment) you can allow LOB users to o som privileged actions, and the attacker will be limited to those as well. Typical example would be to start or stop a daemon/service for a business app (although systemctl can do that with policykit nowadays) – eckes Jun 10 '20 at 10:44
  • 12
    Note that the `fake_sudo` example is capturing the password of an individual user account _which you have already compromised sufficiently to write to its home directory_. Although definitely bad, this is still less bad than the alternatives: users log in directly as `root`, and you compromised _that_ home directory; or users regularly escalate with `su`, and you capture the root password with a similar `fake_su`. At least this way, the sysadmin has clues of which account was compromised. – IMSoP Jun 10 '20 at 22:01
  • 9
    By this logic, all security software and countermeasures ever have 'no real security purpose against a malicious third-party', because yes, as soon as you can get a user to run any executable in any environment, there is very likely a bug or a sneaky way to get root access from there. The point is to make it more difficult. sudo will meaningfuly protect against/slow down malicious attacks in almost all situations, even in your own example it could easily be weeks between invocations of sudo for a standard desktop user. – user2979044 Jun 10 '20 at 22:55
  • @user2979044, not really, because some "security controls" are actually much harder to bypass, and sometimes require having zero-days or continuous research into anti-detection patterns. Instead, this way of "bypassing" sudo is really trivial, has always been trivial, and will continue to be trivial. Because it is not meant to be a security control for the purposes the OP is asking. Note that the OP actually mentioned a scenario where the attacker that can run code, the typical Linux desktop, and issues related to privilege escalation. So I believe my answer is appropriate. – reed Jun 11 '20 at 09:20
  • 3
    Yes @reed, if an attacker already gained full account and system access, and the ability to execute arbitrary code, then pwning the rest of the system is trivial. In other news, the sky is blue. – SnakeDoc Jun 12 '20 at 02:45
127

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.

Bob Coggeshall
  • 1,241
  • 1
  • 3
  • 3
  • 2
    Have you got any way to verify that you are a sudo co-author? Your name isn't mentioned on https://www.sudo.ws/contributors.html – Shadow Jun 10 '20 at 04:01
  • 43
    @Shadow https://www.sudo.ws/contributors.html just lists contributors since 1993, when Todd C. Miller started maintaining sudo. The page you're looking for is https://www.sudo.ws/history.html, which mentions, *"Sudo was first conceived and implemented by Bob Coggeshall and Cliff Spencer around 1980 at the Department of Computer Science at SUNY/Buffalo."* – Eliah Kagan Jun 10 '20 at 04:34
  • 4
    It's still used in that capacity today. Many enterprise customers combine sudo with remote logging to keep an audit trail of who did what. You can also do su + auditd but it's a bit more complex. – Tom Jun 10 '20 at 05:16
  • Excellent, thanks. Hopefully you didn't take that the wrong way, but on the internet there are a lot people claiming to be people they aren't. – Shadow Jun 10 '20 at 06:28
  • 5
    This is exactly why my company made our administrators use 'sudo'. (And changed the root password so that 'su' couldn't be used for root access). If something stopped working, there were sudo logs so we could see who did it and what they did. – AndyB Jun 10 '20 at 20:13
  • 19
    @Shadow :"you didn't write sudo" , Bob :"sudo i did" , Shadow :"ok you did" – workoverflow Jun 11 '20 at 14:44
  • 1
    Excellent, thanks Bob for answering and for co-authoring sudo. As with everything, it has its pros and cons and it's up to us to identify how to make good use of it in a way that has a positive impact on security. – Pedro Jun 11 '20 at 22:36
50

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.

ChocolateOverflow
  • 3,452
  • 4
  • 17
  • 34
  • It's today really easy to gain root (@reed gave a simple example). There is no safe locking it away almost. It's just in a box that is easily findable. – Wernight Jun 08 '20 at 15:37
  • 7
    @Wernight given the example from reed it's more like it's easy to get root if you have user access and the user hands it to you. Yay, sure, if you have user level access it gets a hell of a lot easier to get root If you include interaction with the user (and that user just so happens to give you their root password because they want to do something that requires it or doesn't care that their machine suddenly asks for it). – Frank Hopkins Jun 08 '20 at 16:25
20

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.

Pedro
  • 3,911
  • 11
  • 25
  • 1
    I think the escalation is extremely easy for a standard Linux user. I do `sudo apt update` equivalent all the time. The admin is a fair point even though I don't think most desktop users would set up logging and once an attacker got `root` that person could remove the logs (but that's harder I agree). Never did set that up so far. – Wernight Jun 08 '20 at 15:57
  • 4
    That is entirely dependent on the sudo configuration. It is trivial if the user is allowed to run anything as root, 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 isn't a direct route into root. – Pedro Jun 08 '20 at 15:59
  • 3
    Even when it is trivial to exploit, it depends on the user interacting with the system (by typing a `sudo` command and providing their password). Depending on the system, this could be a significant hurdle all on its own, especially if the attacker's goal is time-sensitive. – jpaugh Jun 08 '20 at 17:26
  • 1
    I think this thread has very good points for system administrators maintaining a park or corporate machine. Such setup allows logging, and it could limit local sudoer actions to only specific binaries for example. I'm not convince that it's the case for most personal computers users (or distro defaults). Still very good points in the corporate case. – Wernight Jun 08 '20 at 17:49
  • @Wernight - I can't speak to other distros, but the Debian default `sudo` config does include logging to `/var/log/auth.log`. Of course, whether the average home user will ever actually check those logs is another question entirely... – Dave Sherohman Jun 09 '20 at 10:41
18

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.

Eliah Kagan
  • 1,315
  • 1
  • 9
  • 12
  • 2
    +1 for logging who did what. That's very handy for later forensics, even when fully internalised. – Criggie Jun 10 '20 at 00:19
17

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.

Jörg W Mittag
  • 1,190
  • 7
  • 11
9

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.

Tom
  • 10,124
  • 18
  • 51
7

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.

Martin Rosenau
  • 339
  • 1
  • 5
5

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.

gmatht
  • 161
  • 3
  • given that in an enterprise setting admins will do 99% of their work remotely, having a key or not makes no difference at all. – Tom Jun 10 '20 at 05:13
  • I guess, but when working remotely I'd use an SSH key for authentication rather than a sudo password. I have made it more explicit that I am only talking about password authentication. – gmatht Jun 10 '20 at 09:13
  • 1
    Linux already has SAK (Secure Attention Key) as Alt+SysRq+K (unless disabled by your distro). However, the *implementation* of that is nearly unusable for normal use which is why it's not used in practice. In addition, `sudo` is often used with remote hosts and there you cannot have SAK by definition. When you access remote system, it all comes to trusting the remote system with any input you provide; if you enter password on any input, the system must be safe. – Mikko Rantalainen Jul 01 '20 at 08:43
  • @MikkoRantalainen You can use remote attestation to verify a remote system's integrity. – forest May 22 '21 at 23:43
  • By "remote attestation" I guess you mean secure boot. I hope that you realize that any system level local exploit can still fake results of that test. Basically, any CVE from this list will be enough: https://www.cvedetails.com/vulnerability-search.php?f=1&co%5B3%5D=1&intg%5B3%5D=1&vendor=linux – obviously, such attack is not trivial but doable. – Mikko Rantalainen May 24 '21 at 08:15
4

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.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
just_floating
  • 41
  • 1
4

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.

James Tocknell
  • 181
  • 5