Every 500 years or so give or take a few hundred 
2 Likes
I guess my point is that hackers who want to remain undetected do not use sudo per default. They rather exploit vulnerabilities to get root access. With that they remain in the shadow.
But anyways, I understand all the points that have been made here. And if I would be responsible for a datacenter with several servers and hundreds of users I would be a lot more careful with sudo. But I am talking here about my PC, single user, behind a firewall and with a firewall on the PC. If somebody has access to my user account the damage is already done. I dont see sudo as a big problem.
In the meantime I have removed the NOPASSWD from my sudo conf. It is just day one of that change and I am already annoyed by typing my password all the time (it is a very long password). I see me ending up with a root shell like ârun0 zshâ and leaving that open. Not sure if that is better than what I had before.
What exactly are you doing that you need root all the time? I only use root per say directly when installing updates. I leverage other rights to power down the machine. Otherwise, most of my activity is in my own user context.
1 Like
I am not sure if this is any better but you can drop in a file in /etc/sudoers.d for the commands you want to run without giving your sudo password. The you just type sudo âcommandâ and off it goes. Maybe this has some security implications too but I have to learn more about it.
That is much better. That means someone would have to compromise that shell.
3 Likes
Almost never. I am seriously considering getting LogWatch or something installed on the system. And that feeds into the whole question of running sudo without password. We can configure systemd-journal to capture all the instances of elevated privileges being invoked, using sudo and other tools. But the only indication of a 3rd party action on the system will be in the journal. That is why elevated permissions, using sudo or some other mechanism, without password is so bad. It just might slip and the user might not be aware.
Do not make the work of a malicious actor easy. Make it hard. It is like vaccination, it gives you a fighting chance to fight the infection. Not prevent it or cure it, but fight it.
@mbod I am not claiming that running sudo without password should not be done. It is upto the user. It is their system and they have to use it. All I am saying that it is not prudent. To save a few keystrokes, which will take less than 30 seconds, is not worth it.
It is just a recommendation. Not a hard and fast rule.
That is very dangerous. If I were to a malicious payload or a hacker that is one of the first few things I would do if I had access to SUDO without password. Maybe a link to a innocuously named script.
1 Like
I wasnât thinking about NOPASSWD for sudo as @mbod has been talking about. I was thinking about running a few common commands you use often which need sudo but without giving the password. But perhaps the security implications for both things are the same?
Had never come across sudoedit before. Been editing as root when required using much clunkier approaches in the past. Very helpful to know. Thx!
1 Like
Some of the points that have been made in this thread are valid points from my point of view. I have already changed my sudo config and eliminated NOPASSWD. And I will not run GUI apps through sudo anymore. I didnât do that very often anyways.
Lets see how that works out for me. May be I need to shorten my password from 25+ characters to just a 4 digit pin 
A 4 digit PIN could then contain 21+ trailing 0âs
I know what you mean, this can get annoying. Especially while testing run0, which does not temporarily cache the elevated status like sudo does. (O/T: I guess it is tricky to implement since the run0 process is designed to be ephemeral; https://github.com/polkit-org/polkit/issues/472).
A while back I configured a YubiKey as an auth method for polkit or sudo, which really takes the curse off a bit because you just have to touch it to authenticate. Obviously itâs a choice that comes with its own security implications (for example, not losing it/allowing it to be stolen), but for a home environment where physical access is low-risk itâs great.
A nice thing about a YubiKey is it cannot be remotely compromised; you must physically touch the device to complete the circuit in order for it to function. So even if the YubiKey was plugged in while someone gained remote access to your computer, they could not use it to authenticate.
By the way, you do not need the OTP version of YubiKey for this; the less expensive âbasic security keyâ model is enough (they are like half the price of the OTP/TOTP version).
A fingerprint reader can be used this way also. My understanding is they are not quite as impenetrable as a YubiKey, but probably sufficient for most common threat models and certainly better than no password. Do some research before you buy one though; a lot of models are not compatible with Linux at all. Here is the libfprint list of supported devices: https://fprint.freedesktop.org/supported-devices.html
Another option that may be worth considering would be using a password manager that has CLI support. After authenticating to the password manager, you could invoke your sudo password with whatever variable or keybinding you have set up (presumably something easier to type than a lengthy passphrase).
Every authentication method comes with its own attack surface of course, and the more options you add the greater the attack surface becomes. But certainly even a relatively flimsy auth method will be more secure than none at all.
1 Like
How often do you need to switch to root? I have added several commands to sudoers so that for those commands I donât need a password. Specifically, pacman and commands like lshw, blkid aso.
Based on all the discussion here about potential hackers and such, pacman would not be a good candidate for sudoâs NOPASSWD from my point of view. Because this would allow a hacker with access to your user account to install any manipulated software package. For example a bash shell with SUID bit set.
Your argument is somewhat specious, since all you have to do to âinstallâ software is cp, or cat, or dd, or any number of other commands.
So if you donât want NOPASSWD on pacman, then you probably donât want it on any command (more or less).
Before I started this thread I had NOPASSWD on ALL commands. Now, with more sense for security and thinking about what a hacker could do with a sudo command that wide open, I take a different approach.
Sure you can install software with cp, cat etc. If you do that as user root you can also copy a bash binary with SUID for user root. That would be a big security whole because then you have a shell on your system that automatically runs with root priviliges. Therefore I would say, that neither of these commands: cat, cp, pacman, paru, yay etc. should have NOPASSWD in sudo.
NOPASSWD seems to be only good for commands which do not manipulate files.
I see it from a practical point of view.
There are two extreme ways
- Using sudo with NOPASSWD for all. Never did this because it is stupid
- Using sudo with PASSWORD for all. Could be done but can be uncomfortabl.
My take is to have something in between as I pointed out in my post above. Everyone has to find their own balance here.
If I were doing things where organizations would like to get into my system I would use Qubes OS without any doubt.
NOPASSWD for pacman, paru, yay is basically a NOPASSWD all because it allows the user to install anything! e.g. a bash shell which runs with root privileges or a manipulated sudo package with NOPASSWD for all.
1 Like
I have sudo ask for my password whenever I use it because it reminds me that I am doing something potentially dangerous and to be careful. It annoys me that sometimes it remembers my authorisation.
Not that I use sudo a lot.
3 Likes
This is what I have now as well. For me this is the consequence of what was discussed here in this thread. I might add harmless commands with read only access like blkid to the NOPASSWD list but I have not done it yet.
2 Likes