Bug 707660 - pam_tally2 counter increases any time sudo prompts for password
Summary: pam_tally2 counter increases any time sudo prompts for password
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sudo
Version: 6.0
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Daniel Kopeček
QA Contact: BaseOS QE Security Team
Depends On:
TreeView+ depends on / blocked
Reported: 2011-05-25 16:27 UTC by Robert Tidwell
Modified: 2018-11-14 12:55 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-06-25 15:49:00 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Robert Tidwell 2011-05-25 16:27:18 UTC
Description of problem:
pam_tally2 is being utilized to deny access after 'x' attempts to sudo with an incorrect password.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. edit /etc/pam.d/system-auth and add the line "auth required pam_tally2 deny=5"
2. run 'pam_tally2 -u <user_name>' (it should be 0)
3. as another user that is allowed to sudo to <user_name> attempt to sudo and supply an incorrect password 'sudo <user_name>'
4. repeat step 3 two more time (that would make 3 attempts)
5. as the user in step 3 use sudo and supply the correct password
6. as <user_name> run 'pam_tally2 -u <user_name>'
Actual results:
the counter should be at 3

Expected results:
the counter should have reset to 0 upon successful login

Additional info:

According to the pam_tally2 documentation:

    Account phase resets attempts counter if the user is not magic root. This
    phase can be used optionally for services which don't call pam_setcred(3)
    correctly or if the reset should be done regardless of the failure of the
    account phase of other modules.

Looking at the source code for sudo, we find this in sudo-1.7.2p2/auth/pam.c:

     * Set credentials (may include resource limits, device
ownership, etc).
     * We don't check the return value here because in Linux-PAM
     * it returns the last saved return code, not the return code
     * for the setcred module.  Because we haven't called
     * this is not set and so pam_setcred() returns PAM_PERM_DENIED.
     * We can't call pam_acct_mgmt() with Linux-PAM for a similar
reason. */
    (void) pam_setcred(pamh, PAM_ESTABLISH_CRED);

As the comment states, pam_authenticate hasn't been called and as the
man page for pam_setcred states:

 It should be called to set the credentials after a user has been
 authenticated and before a session is opened for the user (with

To work around this issue you have to add pam_tally2 to the account section "account required pam_tally2.so" for the counter to reset to 0.

Comment 5 RHEL Program Management 2011-07-06 01:30:12 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support

Comment 8 Daniel Kopeček 2012-03-01 15:13:15 UTC
 after experimenting with different ways how to fix this issue in sudo I think that the "workaround" is the only possible way how to use pam_tally2 in combination with sudo.

Sudo is specific in it's usage of pam since it's authenticating the calling user and then switching to an other user. pam_setcred() is called with PAM_USER set to the target user in sudo, which makes sense. I think that the comment in the code isn't relevant to this problem. If PAM_USER is set to the calling user (the user that is being authenticated), then the counter is set to zero after a successful attempt.

Calling pam_setcred() a second time with PAM_USER set to the target user isn't probably a good idea since the API wasn't meant to be used like that and the call has side effects.

Is the "account phase" workaround acceptable for the customer?

Comment 12 Dalibor Pospíšil 2012-11-06 11:00:18 UTC
Setting qe_test_coverage‑. There is nothing to test.

Note You need to log in before you can comment on or make changes to this bug.