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
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c
- Domain
- authentication
Research direction
Read the linked plugins/sudoers/auth/pam.c section around lines 220–225 and the referenced linux-pam issue for context. The report proposes a distinct PAM service for NOPASSWD commands; first understand how sudo selects its PAM service and how PAM configuration is managed. Done means NOPASSWD commands no longer reset pam_faillock state while ordinary sudo authentication continues to work.
Written by the indexing model from the issue text.
Description
Original bug report that led to this one: https://github.com/linux-pam/linux-pam/issues/842#issue-2598005442 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 https://github.com/sudo-project/sudo/blob/17aa7688c955e58adffdfb0300d485a2b859b128/plugins/sudoers/auth/pam.c#L220-L225, 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.
- Dominant language
- C
- Stars
- 1.7k
- Forks
- 306
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 22
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sudo-project/sudo
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
sudo-project/sudo#583 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
sudo-project/sudo#581 · 4 comments ·
Maintainers usually reply within 1 day
-
Signal forwarded to the command is lost when it arrives between fork() and execve() of the commandOpen
Difficulty 4/5 3-5 days Newbie friendliness 35/100
sudo-project/sudo#566 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
sudo-project/sudo#553 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
sudo-project/sudo#552 ·
Maintainers usually reply within 1 day
All issues in sudo-project/sudo
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zephyrproject-rtos/zephyr#123881 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
eclipse-zenoh/zenoh-pico#1354 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
ly05010419/MacNativeGames#1252 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 2 days