sudo is as secure, or insecure, as its popular alternatives like
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
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
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
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
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
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.