How secure is NOPASSWD in passwordless sudo mode?

Question

On all our boxes we have ssh access via keys. All keys are password protected. At this moment the sudo mode is not passwordless. Because the number of VMs are growing in our setup, we investigate the usage of Ansible.

Ansible itself says in the docs:

Use of passwordless sudo makes things easier to automate, but it’s not required.

This got me thinking about passwordless sudo and I found some questions/answers here. However, I couldn't really find anything about the security concerns of passwordless sudo per se.

It could happen in the future user Bob has a different password on machine X than Y. When Bob is a sudoer, this gives problems with Ansible to enter one sudo password for all boxes. Given the facts ssh is done via keys, keys are password protected and all user accounts have passwords (so su bob is impossible without a password): how is the security affected when NOPASSWD is set in the sudo file?

Answer 1

NOPASSWD doesn't have a major impact on security. Its most obvious effect is to provide protection when the user left his workstation unattended: an attacker with physical access to his workstation can then extract data, perform actions and plant malware with the user's permissions, but not elevate his access to root. This protection is of limited use because the attacker can plant a keylogger-type program that records the user's password the next time he enters it at a sudo prompt or in a screensaver.

Nonetheless, requiring the password does raise the bar for the attacker. In many cases, protection against unsophisticated attackers is useful, particularly in unattended-workstation scenarios where the attack is often one of opportunity and the attacker may not know how to find and configure discreet malware at short notice. Furthermore it is harder to hide malware when you don't have root permissions — you can't hide from root if you don't have root.

There are some realistic scenarios where the lack of a password does protect even against sophisticated attackers. For example, a stolen laptop: the user's laptop is stolen, complete with private SSH keys; either the thief manages to guess the password for the key file (perhaps by brute force), or he gains access to them from a memory dump of a key agent. If the theft is detected, this is a signal to investigate recent activity on that user's account, and this means that a planted malware should be detected. If the attacker only had user-level access, anything he did will leave traces in logs; if the attacker obtained the user's password and ran sudo, all logs are now compromised.

I don't know whether the downsides of NOPASSWD balance the upsides for your use case. You need to balance that against all the other factors of your situation. For example, it seems that you allow but don't enforce having different passwords. Can you instead use a centralized account database? How much containment do you need between your systems? Are you considering alternatives to Ansible that would support differing sudo passwords? Have you considered other authentication mechanisms?

Answer 2

There are two specific cases why you don't want passwordless sudo:

1. This is a defense mechanism against malicious users who gain access to an administrative account. This can either be through exploitation or due to an admin leaving his workstation unattended without locking his session.
2. Having to re-issue the password when using sudo gives impulsive users the time to think twice before actually performing the action.

About automation:

I agree you can do this passwordless, but by not requiring the sudo password you are actually giving ALL access to your automation tool. Now think what the tool is actually required to do? Does it really need all these accesses? Probably not.

Sudo comes with a nice feature which allows you to configure specific commands with the NOPASSWD flag within the sudoers file:

username myhost = (root) NOPASSWD: /sbin/shutdown
username myhost = (root) NOPASSWD: /sbin/reboot

Answer 3

One thing it doesn't look like anyone's pointed out for some reason (correct me if I'm wrong) is that it enables any program you run to elevate to root access without you knowing. Normally, if you accidentally run a malicious program or script as a non-root user without sudo, then while it may still be able to do a lot of damage, it still (barring a separate exploit) won't have root privileges. So you at least won't need to worry about a rootkit or anything. But with NOPASSWD mode, you don't have that protection. Any program that runs under your user will be able to escalate to root by re-invoking itself with sudo. The malware still needs to specifically be programmed to do this, and it won't have root access otherwise, but then what about malicious code that does do that?

Answer 4

Given the facts ssh is done via keys, keys are password protected and all user accounts have passwords (so su bob is impossible without a password)

Let's be clear here. The passwords used to protect the SSH keys and the passwords of the user accounts ARE NOT THE SAME ONES.

NOPASSWD simply allows the user to execute commands as another user without entering his password. It does not affect the fact that the user has to enter his password when SSH-ing into the system.

Answer 5

Ansible can use various things for automation: like sudo with a sudo password, or NOPASSWD. Or use su, suexec, doas, or whatever.

Nowaday we speak of:

become: yes
become_user:root
become_method: sudo

Just bear in mind that ideally ansible should be used for automation (infra as code), not for interactive use. Human users could still use passwords, incidentally they might stumble upon expiration policies.

Ansible Tower and AWX can store all kinds of credentials encrypted and delegate their use for specific jobs, without leaking the keys or passwords.

An alternative is using temporary (signed) ssh keys. Hashicorp Vault can manage those

Answer 6

There are pros and cons to having the user enter a password to access sudo.

Pro: better protection if someone gains access to an admin account. eg through an unlocked terminal, or some sort of exploit.

Con: the user is entering a plain text password which is encrypted in transit, but then decrypted before it reaches the user's shell. Someone could for example tamper with the bashrc script to run a key logger. Depending on your setup, and the users' habits that might permit use of the password for direct login to the users account on this machine, and perhaps on other machines as well. People re-use passwords all too often.