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
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 30/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- c
- Bereich
- authentication
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- C
- Sterne
- 1.7k
- Forks
- 306
- Ø Merge
- 1 T. 2 Std.
- Gemergte PRs (30 T.)
- 22
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus sudo-project/sudo
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 42/100
sudo-project/sudo#583 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
sudo-project/sudo#581 · 4 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Signal forwarded to the command is lost when it arrives between fork() and execve() of the commandOffen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
sudo-project/sudo#566 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 52/100
sudo-project/sudo#553 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
sudo-project/sudo#552 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in sudo-project/sudo
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
libsdl-org/SDL#16607 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
PowerShell/Win32-OpenSSH#2482 · 1 Reaktion ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
OpenMathLib/OpenBLAS#6192 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
Maintainer antworten meist innerhalb von 2 Tagen