Hacker News Reader

All security is just putting roadblocks in place to buy you time to notice and to make you an unattractive target, same physically as digitally (you don't really think your front door lock will keep someone out that really want in, right?).

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.

> you don't really think your front door lock will keep someone out that really want in, right?

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.

What is your house made of? How can you have multiple ways of entering a house without any damage if you have walls, doors and windows? What else is there?

Doors and windows are designed to open, and frequently they don't lock automatically (or the lock is VERY insecure). There are crawl spaces, attics, mail slots, balconies, garage doors, etc. that frequently connect the outside to the inside.

Two out of three ;)

Don't forget the chimney. Ho ho ho!

> How can you have multiple ways of entering a house without any damage if you have walls, doors and windows?

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.

I live in a rather modern European apartment/condo and I don't think this would be true for my home at all. Sure, with the right tools you can get windows or doors open, but it will be very loud and not that easy. Windows are triple glazed (for insulation, not protection) and they have a fair amount of locks on all sides (can be annoying as they won't close if any of those are blocked by dirt or leave).

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.

Apartments are probably harder than houses, fewer points of entry pretty much ensure that. But I've lived in apartments as well and in fact a few years ago in Bucharest I had to do something quite similar and that worked just fine as well. It all depends on how much you know about how stuff is put together to be able to spot the weak points in a structure. But a properly designed and implemented security layer for an apartment would be hard or even impossible to crack without damage. The devil is in the details though and compared to a thief, if it is your own place you have a lot of motivation not to damage it and a lot of time.

I have one "shut myself" out of my apartment when I have replaced the tag and a draft closed the door - when I realized, I don't have any keys. I knew, one window was angle opened in the kitchen right next to the balcony. I asked my neighbours, if I could climb over. It was the third floor, so I kind of hesitated, but there were multiple robust things I could hold onto. I used my belt to move the handle of another window 90° so it would open like a door through just the 5 cm opening at the top of the other window.

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.

Regular viewers of The Lock Picking Lawyer on youtube know how trivial it can be to bypass many common locks. Especially if you pickup a 10 dollar tool for the job. And I don't mean trivial for the LPL, I mean just trivial for a lay person who is aware of the vulnerability.

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

Oh that's hilarious. He could have done four in that time.

> Passworded sudo is just another roadblock to give you more time.

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" :)

> The problem with this world-view is that it's a fallacy.

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.

Passworded ssh keys can be valuable - if I steal your laptop while it’s on, I can use DMA hacking or frozen ram kind of techniques to extract secrets out of memory. If your SSH keys have a password on them, I have a limited time to perform said attacks.

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.

If you're a sysadmin for a large company or if you're a public person then I'd agree, but I believe for 99% of us, no one would spend the time to perform these attacks on stolen hardware. And even for large companies, they'd just look for the next sysadmin who has their password on a post-it on the laptop or in their bag (still happens enough).

Yeah but op was questioning real security model without context. I don’t disagree with you, security and threat models are highly contextual.

It really depends. There's honestly a really big difference between user and root on Linux, so handing root over is probably not ideal. That said, how you deal with this is up to you and very specific to your infrastructure and security posture.

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".

> 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.

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.

Yeah but you can harden against that. You can:

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.

Alright, instead, knowing this, I shall simply change the configuration of your terminal emulator to use a wrapper script I wrote. It'll inject a script into the shell to alias sudo to my evil variant. The evil variant will instead of calling whatever you wanted with sudo instead call itself and first worm into the system with root, then continue execution with what you wanted. A simple scan should reveal running services and the executable will disguise itself as those, ideally by writing to files that the original sudo command would have written to. Like, if you sudo crontab -e, then I shall simply worm into your crontab and wrap access to it to hide the actual contents. Once that is done I can go into manipulating your audit to hide myself before continuing with more nefarious things.

I'm not sure I understand this attack. You're some process under a uid, say 1000. I SSH into the box and get a shell at uid 1000.

You're describing an attack where you configure my terminal to use a wrapper script? What exactly does that entail?

Well for SSH you can simply edit the authenticated_keys file to get what you want.

Sorry, I'm still not understanding your attack. As a user on the system, which files are you writing to exactly in order to execute this attack you've described?

Any configuration files of programs the user might call, such as editors, ssh, terminal emulators, shells or anything the user regularly executes.

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.

I'd be interested in hearing more about the specific for some of these, but others seem unlikely to work.

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.

i mean sure there will be several dozens ways to compromise your machine once your user account is wide open already... but allowing any script or software to run any command privileged without any questions asked? there is certainly a risk attached to that and not even necessarily related to an active attack... you are one badly written script away from doing something dumb without even noticing it...

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...

Optimally, password authentication would be hardware protected. Meaning, for instance, there was a dedicated LED on your system that you'd need root rights to toggle, and any password request thrown up would need to light up that LED to indicate that it's the actual dialog, rather than a fake. - A similar, less invasive solution could be randomizing the password dialog background color when your user account is set up.

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.

It's not just sudoers accounts, the reality is that privilege escalation vulnerabilities are very common on Linux systems, particularly if you run uncommon drivers. So any sort of code execution, even on an unprivileged account is generally game over.

Qubes OS does exactly that [0], but the security actually relies on virtualization there.

[0] https://www.qubes-os.org/doc/vm-sudo/

> 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 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.

> 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.

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?

> If I have your ssh keys, haven't I only won if you're not also using a password?

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.

If someone has my private keys because they stole my laptop, then a keylogger will do them no good, and the password will be a valuable layer of defense.

It is a good idea to use disk encryption anyway.

Yes, that too!

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.

> 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.

Isn't this only true assuming the private key isn't backed up somewhere?

You mean assuming they don't get your private key from the backups.

But then you want to encrypt all the backups and not just the private key, right?

You should still use passwords with SSH keys to ensure that they're encrypted on disk. An SSH agent makes the user experience not annoying, so there's no point in opting out of the extra security.

You can switch to short-lived signed SSH keys and protect the CA key with all the measures.