You definitely have the right idea. The thing is, sudo
isn't really meant to protect you in what is essentially a single-user environment. When I say "single-user", I don't mean that Linux doesn't understand the concept of different users, because you certainly have more than a dozen different users on your machine right now; I mean you are most likely the only real person using your machine.
Home vs. Enterprise Environments
In what I call a "home" environment, a machine either only has one person using it, or possibly a couple (think "family computer), but splitting people into users is more a convenience thing. Dad, who uses the machine for work primarily, doesn't want to be bothered by countless games being installed on the machine. Likewise, the son doesn't care about all the work documents, he just wants to play games.
In an enterprise environment, it's very likely that some server has hundreds of user accounts registered, all with different roles and permission. This is the environment sudo
was created for. You don't want to give everyone permission to execute everything as root, so just using su
is a bad idea. Perhaps you want Alice to be able to do that, but Bob is only allowed to run /sbin/mcguffin
as root via sudo
. All of this can be set up via the /etc/sudoers
file.
Privilege Escalation of Malware
There are several ways malware can escalate its privileges. For example, if you've recently used sudo
, and then invoke it again, you will see that it won't ask you for your password. This is because sudo
can be configured (and on many systems, this is enabled by default) to use "tickets", which essentially enables you to use sudo
without typing your password for a short period of time. If you currently have a valid ticket, then malware can simply use this ticket to perform a task as root and there is not much you can do about it.
Another possibility, as you correctly recognized, is monitoring keystrokes. While I am not 100% sure if a compromised browser would allow you to monitor keystrokes in general, there is a different option: Modifying the user's shell environment to run a wrapper around sudo
. Essentially, when the user tries to use sudo
, they actually run the script provided by the malware, which logs the password and then uses it to run sudo
on behalf of the user. To the user, this process is transparent (unless they set up /etc/sudoers
to use the NOPASSWD
directive, in which case the malware doesn't need passwords in the first place).
In essence, as a single user, you don't really get any protection from sudo
.
Possible Mitigations
One possible way to mitigate this is to create a separate user account, which does not have sudo
privileges. Depending on your workflow, you may even simply automate all tasks which require administrative privileges, such as installing system updates. However, if you frequently have to switch between a privileged and non-privileged account, it may be possible for malware to get the credentials to the privileged account, which renders this approach only marginally better.