8 ms·

> once you manage to gain access to the support teams' computers you also now have a gateway into all the other machines that they support Speaking of which, w

> once you manage to gain access to the support teams' computers you also now have a gateway into all the other machines that they support 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.

hsbauauvhabzb 5y ago
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.
- dx034 5y ago
  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).
  - hsbauauvhabzb 5y ago
    Yeah but op was questioning real security model without context. I don’t disagree with you, security and threat models are highly contextual.
Eelongate 5y ago
> 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.
- staticassertion 5y ago
  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.
  - zaarn 5y ago
    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.
    - staticassertion 5y ago
      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?
stefan_ 5y ago
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.
kbenson 5y ago
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.
- jacquesm 5y ago
  > 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.
  - kungito 5y ago
    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?
    - dghlsakjg 5y ago
      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.
montroser 5y ago
> 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?
- AnthonyMouse 5y ago
  > 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.
  - montroser 5y ago
    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.
    - vbezhenar 5y ago
      It is a good idea to use disk encryption anyway.
      - montroser 5y ago
        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.
  - 5y ago
chousuke 5y ago
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.
mercora 5y ago
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...
staticassertion 5y ago
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".
fsflover 5y ago
Qubes OS does exactly that [0], but the security actually relies on virtualization there. [0] https://www.qubes-os.org/doc/vm-sudo/ https://www.qubes-os.org/doc/vm-sudo/
FeepingCreature 5y ago
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.
chupasaurus 5y ago
You can switch to short-lived signed SSH keys and protect the CA key with all the measures.
rascul 5y ago
> 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.

hsbauauvhabzb 5y ago

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.

dx034 5y ago
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).
- hsbauauvhabzb 5y ago
  Yeah but op was questioning real security model without context. I don’t disagree with you, security and threat models are highly contextual.

Eelongate 5y ago

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

staticassertion 5y ago
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.
- zaarn 5y ago
  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.
  - staticassertion 5y ago
    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?

stefan_ 5y ago

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.

kbenson 5y ago

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.

jacquesm 5y ago
> 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.
- kungito 5y ago
  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?
  - dghlsakjg 5y ago
    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.

montroser 5y ago

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

AnthonyMouse 5y ago
> 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.
- montroser 5y ago
  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.
  - vbezhenar 5y ago
    It is a good idea to use disk encryption anyway.
    - montroser 5y ago
      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.
- 5y ago

chousuke 5y ago

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.

mercora 5y ago

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

staticassertion 5y ago

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

fsflover 5y ago

Qubes OS does exactly that [0], but the security actually relies on virtualization there. [0] https://www.qubes-os.org/doc/vm-sudo/ https://www.qubes-os.org/doc/vm-sudo/

FeepingCreature 5y ago

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.

chupasaurus 5y ago

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

rascul 5y ago

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