Speaking of which, what is everyone here’s view on allowing passwordless sudo on Linux servers?
In my mind, if someone has already gained access to my user on the server, which has sudo privileges, they are only a couple of steps away from be able to take control over the server anyways. So I allow sudo without password on my servers.
sudo password is basically nothing but an annoyance.
Likewise, my ssh keys are also not password protected. If you are able to read my ssh keys, you have already won anyways. No point to me in having a password on them.
Where I do take extra steps instead include:
- I disable password based authentication for sshd, allowing only keybased authentication.
- On some servers I have sshd listening on WireGuard interfaces only.
- My personal devices use full disk encryption.
- I lock computers and other devices when I walk away from them.
- I use 2FA for any third-party services of importance such as mail etc, preferring TOTP/HOTP if available. Or SMS based if that’s the only option even though it’s not very good it’s something.
- I use an adblocker in the browser on my computers.
- I am careful not to get tricked by phishing emails, phishing SMSes and other scam messages.
- I install software from trusted sources mainly.
- I use an iPhone, not Android.
I’m pretty satisfied about my own computer security.
Next step I need to handle is proper backups. I have too many files that are stored in n=1 locations. I have some of the most important files in n>=2 locations, but still there are many important files that I don’t.
For that reason, I’d prefer passphrase backed keys, even if they had very long (36h+) expiry time.
Edit: one cool hack I use is a conplex FDE password, but relatively simple /etc/shadow password - this saves a huge amount of effort.
This seems like sound logic to me. If you have write permission to their bashrc, it's trivial to change their path to include a keylogging wrapper for sudo. The next time they use sudo, you have their password. If an attacker has gotten that far, a password on sudo seems like closing the barn doors after the horses already ran off.
1. Audit writes to paths like bashrc (I've written this alert and many others like it)
2. Audit writes from processes under uid X to files in uid Y's home
3. Limit the need to sudo in the first place
4. Add a TOTP auth to sudo
5. Limit the ability for arbitrary processes to write to arbitrary files (containerize your shells, services, etc).
The thing is that all of the above assume the attacker isn't already root. If the attacker is root, this all becomes a lot harder.
You're describing an attack where you configure my terminal to use a wrapper script? What exactly does that entail?
Every binary that loads data from the user directory for user configuration is a vector for further inserting oneself into the system.
The spellcheck function of Nano can be exploited to spawn a subprocess that takes over the session. When you exit Nano, you're exiting this new subprocess and end up in a shell that has been manipulated.
Same for Vim.
SSH can be manipulated into replacing your shell easily by editing authorized_keys.
If a program has write access to your home directory, you cannot trust the shell you open.
Even something as innocous as git status being included in your prompt can be abused to gain control of your shell session. Once you have that you just wait for sudo to be entered or you manipulate the shell to execute an attacker's code instead of sudo when called.
For example, there's no reason for a user to have read, let alone write, access to authorized_keys.
Read and write access for users is way overly permissive by default, but it's really easy to fix that.
I do agree that you can't trust the shell if a user is compromised though. But this is about preventing an attacker from gaining root access, which means you now can't trust the entire system (since they can just shut off security controls).
Also keep in mind that all of these described attacks require performing auditable actions. If an attacker can trivially, quickly escalate, you can't trust your auditing.
Passworded sudo is just another roadblock to give you more time. Passwordless means instead of the attacker getting local root and then having to find an exploit, they immediately get to escalate to root. For very sophisticated attackers, it may by a trivial difference in time, but for unsophisticated ones it may mean they don't get root to do more damage.
And given that sophisticated attackers are ones you can't really guard well against without a whole department devoted to it, unsophisticated ones are probably ones you should really make sure not to ignore.
I recently had the - unfortunate - opportunity to put this to the test. The house I live in has the highest grade burglary protection that you can still buy for normal money (courtesy of the previous owner). It still only took me 35 minutes to break into it when I accidentally closed the door behind me when there was nobody else home. This kind of surprised me, because I didn't have access to any tools at all, just the stuff that was laying around in the garden (some sticks and a little bit of steel wire). And all that without breaking anything, if that constraint would not have been there the 35 minutes would have been reduced to 30 seconds, tops.
Later I figured out three other ways to get in without any damage, but most of those would have cost a bit more time.
Given that it is pretty trivial to find out where I live I'm not going to write that up here, you're going to have to take my word for it. But the hacker mentality applies to houses just as it applies to servers. You just need to think a bit more adversarial.
If you just close the door without locking it, it's possible to open them without causing too much damage. But I heard from neighbours who got locked out that if you have your door locked, even a locksmith will at least need to destroy the lock, potentially even part of the door, to get inside.
There's no such thing as perfect protection, but most thieves will ignore objects that take longer than a minute or two to break in to. There are too many alternatives and any minute spent at the door increases the risk of detection.
Also, apart from doors or windows there are no openings. There's ventilation but the diameter is way too small to crawl through. And access from parking is secured the same way as through the front door.
So yes, I think a front door lock will keep out thieves. Not because it makes it impossible but because it's just not worth it. Same as a well protected server all but keeps out intruders. Unless you're a very high value target, they go after easier targets first.
Nobody saw me, nobody asked anything. I could perhaps climb to the balcony easily even though I don't do any climbing otherwise. After this, I never left the apartment with any angle-opened window after that.
Unrelated, here is my favorite LPL video where a locksmith calls bullshit and challenges LPL to a duel: https://www.youtube.com/watch?v=NSuaUok-wTY
The problem with this world-view is that it's a fallacy. You're assuming that people won't be bothered by having to re-type their password all the time, and just implement a "secure" script using a setuid bit instead.
Now someone else intentionally adds the ability to allow that script to execute arbitrary commands and you've got a vulnerability with passworded sudo that would have never happened with passwordless sudo.
I've seen that same story happen countless times in the real world. E.g. a company I worked for went from a "bastion" login system (authenticate once) for the sysadmin "run a command on the fleet" interface of last resort to requiring "re-authentication on login", which now needed a re-login with a OTP for each machine, in a datacenter with quite a few machines.
That's conceptually the same as insisting on passworded sudo in terms of security. Guess what happened next in that setup? No points for "sysadmins just got used to re-typing their passwords in the for-loop" :)
There's nothing fallacious about the concept that security controls are just roadblocks. There is no such thing as perfect security for a system that requires someone to be able to access or use it. All security controls do is provide time and/or notification of someone trying to break in, if all goes well. Then you can hope to mount a more active defense of some sort if needed.
> You're assuming that people won't be bothered by having to re-type their password all the time, and just implement a "secure" script using a setuid bit instead.
Obviously there's a trade off for how cumbersome it is to use something in an authorized manner and how much people will attempt to work around that inconvenience. What is a fallacy is that any inconvenience in the same of security is not worthwhile.
In many configurations of sudo shipped by default in common distros, it caches your auth for that tty for a number of minutes, so after you auth you don't have to auth again for a while. You can easily change this, and make it so that after you auth in a tty, you won't have to auth again for 24 hours if you wanted. You would still have quite a bit of protection from attackers (at least those that weren't at an unlocked screen of yours with one of those terminals), and entering a password once a dayis probably acceptable to most people (in reality, once a day per terminal they want to use it in, but it's not hard to keep one terminal open for secure use).
> Now someone else intentionally adds the ability to allow that script to execute arbitrary commands and you've got a vulnerability with passworded sudo that would have never happened with passwordless sudo.
It's hard to protect against stupidity. Either train people to not to stupid things, or if your security policy is actually too onerous, then reassess what the correct policy should be and implement it. To be clear, I doubt the correct policy is "let's just turn off all the security because we're lazy".
> That's conceptually the same as insisting on passworded sudo in terms of security.
It's easy to say it is, because almost everything is conceptually the same thing if you boil them down to a few related concepts and attributes and then ignore the magnitude and impact of those things. I mean, shooting someone with a Nerf gun and shooting someone with a Glock are conceptually the same things, right?
So, please, let's not act like having to enter your password once every few minutes when needed for root access (or longer, if you configure it to) is equivalent to jumping through multiple systems, authing additional times at each level, and requiring OOB auth additionally. If you're really annoyed by sudo, just "sudo bash" and keep the terminal open. At least you still get some protection from local user access privilege escalation.
None of this is ever so black and white. If I have your ssh keys, haven't I only won if you're not also using a password? Otherwise, all I have is your ssh keys, which granted, is bad, but defense-in-depth, no?
In general if someone has enough access to get your ssh private keys, they have enough access to log the next time you type the password.
> Otherwise, all I have is your ssh keys, which granted, is bad, but defense-in-depth, no?
Everything is trade offs. In order for the password to not be completely worthless, it has to be complex enough to not be trivially broken by password crackers. But then it's long and hard to type. If you have to type it a lot, and all it's buying you is that the attacker has to wait for the next time you type the password, that's a poor cost benefit ratio.
Disk encryption, aggressive lock screen timeouts, etc -- that's all good stuff in addition.
But the point is that defense-in-depth works, and passwords can be a meaningful part of the strategy.
Isn't this only true assuming the private key isn't backed up somewhere?
But then you want to encrypt all the backups and not just the private key, right?
and not having to confirm anything to use your ssh keys means not only your machine is compromised but all of those that those keys allow access to are potentially compromised too now... i use an ssh-agent (gpg-agent implementation) to only ask once at the start of my session for the password and every time for confirmation of usage or after some time without usage it will ask for the password again. its not annoying at all...
For example, the obvious question is probably "why is anyone sudo'ing". A lot of operational capabilities don't need sudo. Some do.
Rather than handing over passwordless sudo, you can provide binaries that can execute with the required permissions but provide a much more granular interface. For example, if you need to take a memory dump of a service the binary could be set up to only allow that capability and to only work on a set of services.
Further, you may want to audit sudo access but allow it. If you remove the need for root capabilities for engineering purposes you should see sudo very rarely and be able to alert on that - but obviously this assumes you have an instrumentaiton pipeline set up.
Speaking of instrumentation, it's one of the major reasons why you don't want to just hand root over. An attacker with root can more or less just turn instrumentation off. An attacker without root is auditable.
For your specific situation your current security posture could be fine. For a large company they may want to do more.
The tl;dr is really that, yeah, on some default Linux system where you assume an attacker is executing within your user already, a password on sudo isn't gonna help much. But obviously you should harden that server, and a big part of that is going to be "how do I keep the attacker from getting root".
Now, given we don't do any of that shit, it's trivially easy to hijack a root/ssh key password request by just faking the dialog. In that sense, you may as well go passwordless. However, IMO going passwordless is tantamount to admitting not just that our security sucks, but that our security is going to suck forever. Seems kind of defeatist.
Sudo can use root password instead of user password. Possibly other auth mechanisms also. It may be better to fine tune sudoers than to leave it wide open.