Bizarre pam_tally / sudo error: locking me out, "tally underflowed"

AlucardZero · 09-02-2010, 02:43 PM

I have a SLES 11.1 (PPC) server that keeps locking me out even when I don't fail logins. I determined that when sudo asks for my password, even when I authenticate correctly on the first try, my fail count is increased:

Code:

alucard@fileserver:~$ sudo /usr/sbin/faillog -u alucard
Login       Failures Maximum Latest                   On
alucard         0        0   09/02/10 15:30:44 -0400  /dev/pts/1
alucard@fileserver:~$ sudo -k
alucard@fileserver:~$ sudo /usr/sbin/faillog -u alucard
alucard's password:
Login       Failures Maximum Latest                   On
alucard         1        0   09/02/10 15:30:58 -0400  /dev/pts/1

Why would sudo do this? sudo-1.6.9p17-21.3.1 is the package version installed.

Here's what the log says:

Code:

alucard@fileserver:~$ sudo tail /var/log/auth.log
Sep  2 15:30:45 fileserver sudo:  alucard : TTY=pts/1 ; PWD=/home/alucard ; USER=root ; COMMAND=/usr/sbin/faillog -r -u alucard
Sep  2 15:30:49 fileserver sudo:  alucard : TTY=pts/1 ; PWD=/home/alucard ; USER=root ; COMMAND=/usr/sbin/faillog -u alucard
Sep  2 15:30:58 fileserver sudo:  alucard : TTY=pts/1 ; PWD=/home/alucard ; USER=root ; COMMAND=/usr/sbin/faillog -u alucard
Sep  2 15:30:58 fileserver sudo: pam_tally(sudo:setcred): Tally underflowed for user root
Sep  2 15:31:09 fileserver sudo:  alucard : TTY=pts/1 ; PWD=/home/alucard ; USER=root ; COMMAND=/usr/bin/tail /var/log/auth.log

"Tally underflowed for user" only has two Google results before this post, both of which are chat logs and neither of which help. Any idea what the heck it means?

I have changed two PAM files as follows due to security requirements. The entire contents of the files follow.
common-password-pc:

Code:

password        requisite       pam_pwcheck.so  nullok cracklib 
password        required        pam_unix2.so    use_authtok nullok md5 shadow remember=7

common-auth-pc:

Code:

auth    required        pam_env.so
auth    required        pam_unix2.so
auth    required pam_tally.so deny=5 

account required pam_tally.so

Ideas?

anomie · 09-02-2010, 03:29 PM

I don't use SLES, but I'm presuming that common-auth-pc is an include used by both sshd's PAM config and sudo's PAM config (and probably some others).

Out of curiosity, do your security requirements state that you must use pam_tally for all PAM-enabled services, or would they be satisfied if you were to enable it for only sshd?

(I think you can see what I'm getting at. I don't have a direct answer to your sudo + pam_tally issue, but if policy doesn't require it you could simply stop including common-auth-pc in sudo's PAM config, and instead directly require pam_env and pam_unix2 there.)

AlucardZero · 09-02-2010, 03:42 PM

Looks like I can't without breaking the requirements. They state that the modifications must appear in the common control file or "in all /etc/pam.d control files which require login authentication."

unSpawn · 09-02-2010, 05:30 PM

Quote:

Originally Posted by AlucardZero

"Tally underflowed for user" only has two Google results before this post, both of which are chat logs and neither of which help. Any idea what the heck it means?

Quickest source I could find w/o having to D/L the .src.rpm was https://fedorahosted.org/pam-redhat/...y2/pam_tally.c :

Code:

89 	#define tally_t    uint16_t
90 	#define TALLY_FMT  "%hu"
91 	#define TALLY_HI   ((tally_t)~0L)
(..)
589 	      if (tally.fail_cnt == TALLY_HI) { /* Overflow *and* underflow. :) */
590 	          tally.fail_cnt -= inc;
591 	          pam_syslog(pamh, LOG_ALERT, "Tally %sflowed for user %s",
592 	                 (inc<0)?"under":"over",user);
593 	      }
594 	    }

a warning for overflow seems OK but for underflow?..

Quote:

Originally Posted by AlucardZero

Why would sudo do this? (..)

Code:

Sep  2 15:30:58 fileserver sudo: pam_tally(sudo:setcred): Tally underflowed for user root

It's not Sudo doing this. Sudo is only the PAM "service", as your log shows it's pam_tally doing "setcred". From /usr/share/doc/pam-/txts/pam_tally2: "Authentication phase first checks if user should be denied access and if not it increments attempted login counter. Then on call to pam_setcred it resets the attempts counter if the user is NOT magic root.". (The pam_setcred function is used to establish, maintain and delete the credentials of a user. It should be called after a user has been authenticated).

Now I don't use SLES either but I know PAM provides two tally modules: pam_tally and pam_tally2 which seems to be a complete rewrite of pam_tally. Maybe it's worth testing but note pam_tally2 doesn't use /var/log/faillog but its own file because of changed format. There's also options to play with like unlock_time=n which could keep you from getting locked out completely and no_reset, maybe only decrementing the counter may work. If *that* doesn't work please check the vendors bug tracker for any clues. If none show up you could see if a version for a recent version of OpenSUSE works and if rebuilding it for your SLES wouldn't invalidate any commercial support. If that doesn't work for you then you could diff the pam_tally version you use with one anyone of us uses here (pam-0.99.6.2-6.el5_4.1.i386 here) to see if there's any differences. Doubtful but could happen. If that doesn't work for you then you have exhausted all other options and the only suggestion I can make is to call in support, after all SLES is an Enterprise product...

AlucardZero · 09-08-2010, 01:06 PM

Solved by adding the account line to common-account:

Code:

account required pam_tally.so

With that my account is still locked due to SSH login failures, but not due to successful sudos anymore.

Here's /etc/pam.d/sudo for reference:

Code:

#%PAM-1.0
auth     include        common-auth
account  include        common-account
password include        common-password
session  include        common-session
# session  optional       pam_xauth.so

Note how it doesn't include common-auth under "account." On RHEL 5, both auth and account phases include system-auth, and previously on this SLES11 I hadn't modified common-account. So that's why this happened to me.

unSpawn · 09-08-2010, 01:17 PM

Excellent. Well done!