NOPASSD exceptions in `/etc/sudoers(.d)` interact poorly with `pam_faillock`, no configuration option available to allow sudo to tell PAM when a NOPASSWD command is being run

[ArrayBolt3]

Original bug report that led to this one: linux-pam/linux-pam#842 (comment) This "bug" technically has security implications, but I don't believe they're major enough to warrant treating this as a security vulnerability.

PAM has a module, pam_faillock, that allows locking out a user account after a certain number of failed authentication attempts. If the user under attack is not logged into by anyone else, this can work well, however if the account being attacked is logged into and actively being used, it is possible to unlock the account or reset the failed login tally by running a command with sudo that has a NOPASSWD exception present in /etc/sudoers(.d). PAM will see this as a successful authentication, and depending on how PAM is configured it will very likely reset pam_faillock's state directory when this happens, thereby unlocking the account or resetting the tally.

The reason this happens in typical pam_faillock configurations is because sudo usually goes uses the same PAM configuration as most other applications that authenticate users. The configuration will usually integrate pam_faillock directly into the default auth flow, meaning that a failed sudo authentication will count as a failed login, while a successful one will count as a successful login. pam_faillock handles successful logins by resetting the failed login tally that it keeps. This is all well and good, except for the fact that sudo uses the exact same auth flow for basically anything other than sudo -i. Running a command that is given a NOPASSWD exception results in a successful authentication, which PAM then handles as a successful login, which pam_faillock then handles as a "I can reset the failed login tally now" signal.

This is particularly problematic for at least one project (Kicksecure) which uses pam_faillock to prevent a malicious user who gains access to a user account that has sudo privileges from elevating to root by guessing the user password. After enough failed sudo runs, the account is locked and sudo becomes unusable until a legitimate user comes along and unlocks the account. However, due to sudo's interaction with pam_faillock when using NOPASSWD exceptions, a malicious user can trivially bypass this lock by simply running any command that has a NOPASSWD exception every time the account becomes locked.

The current solution I have envisioned for this is that sudo could add another PAM service to

sudo/plugins/sudoers/auth/pam.c

Lines 220 to 225 in 17aa768

	if (ISSET(ctx->mode, MODE_ASKPASS) && def_pam_askpass_service != NULL) {
	pam_service = def_pam_askpass_service;
	} else {
	pam_service = ISSET(ctx->mode, MODE_LOGIN_SHELL) ?
	def_pam_login_service : def_pam_service;
	}

, which would identify sudo-nopasswd differently from sudo. This would allow one to write a PAM configuration that only involved pam_faillock with typical sudo runs, and kept it out of the auth flow for NOPASSWD commands. That way NOPASSWD commands would still succeed, but they would not unlock the account.