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.