Bug 193654 - using pam_tally and sudo, every succesful sudo is a login failure
using pam_tally and sudo, every succesful sudo is a login failure
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: sudo (Show other bugs)
2.1
All Linux
medium Severity high
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-31 09:29 EDT by Dag Wieers
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-31 17:56:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dag Wieers 2006-05-31 09:29:04 EDT
Description of problem:
We see the following problem on all our AS2.1 servers. Everytime we run a
command using sudo it is counted as a login failure, even when the password was
correct and the command run successfully.

We are using the following pam configuration:

   [root@system root]# cat /etc/pam.d/sudo 
   #%PAM-1.0
   auth       required     /lib/security/pam_stack.so service=system-auth
   account    required     /lib/security/pam_stack.so service=system-auth
   password   required     /lib/security/pam_stack.so service=system-auth
   session    required     /lib/security/pam_stack.so service=system-auth

   [root@system root]# cat /etc/pam.d/system-auth
   #%PAM-1.0
   # This file is auto-generated.
   # User changes will be destroyed the next time authconfig is run.
   auth        required      /lib/security/$ISA/pam_env.so
   auth        required      /lib/security/$ISA/pam_tally.so onerr=fail
no_magic_root
   auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
   auth        required      /lib/security/$ISA/pam_deny.so

   account     required      /lib/security/$ISA/pam_unix.so
   account     required      /lib/security/$ISA/pam_tally.so deny=3
no_magic_root reset

   password    required      /lib/security/$ISA/pam_cracklib.so retry=3 minlen=8
difok=3
   password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok
md5 shadow remember=5
   password    required      /lib/security/$ISA/pam_deny.so

   session     required      /lib/security/$ISA/pam_limits.so
   session     required      /lib/security/$ISA/pam_unix.so

Here is the demonstration. Let's make sure there are no login failures:

   [root@system root]# /usr/bin/faillog -r
   [root@system root]# /usr/bin/faillog   
   Username   Failures  Maximum  Latest
   user              0        0  Wed May 31 15:19:41 +0200 2006 on pts/0

Then I log on and use sudo:

   [user@mgmt user]$ ssh user@system
   NOTICE TO USERS

   Use of this machine waives all rights to your privacy,
   and is consent to be monitored.
   Unauthorized use prohibited.


   user@system's password: 
   Last login: Wed May 31 15:03:50 2006 from mgmt
   NOTICE TO USERS

   Use of this machine waives all rights to your privacy,
   and is consent to be monitored.
   Unauthorized use prohibited.


   [user@system user]$ sudo faillog
   Password:
   Username   Failures  Maximum  Latest
   user              1        0  Wed May 31 15:20:07 +0200 2006 on pts/0
   [user@system user]$ sudo -k
   [user@system user]$ sudo faillog
   Password:
   Username   Failures  Maximum  Latest
   user              2        0  Wed May 31 15:20:42 +0200 2006 on pts/0


Version-Release number of selected component (if applicable):
   [root@system root]# rpm -q pam shadow-utils sudo
   pam-0.75-46.64
   shadow-utils-20000902-13.7
   sudo-1.6.5p2-1.7x.1

How reproducible:
Everytime

Steps to Reproduce:
1. See demonstration
2.
3.
  
Actual results:
Login failures increase while it shouldn't.

Expected results:
It shouldn't.

Additional info:
Comment 1 Dag Wieers 2006-05-31 09:41:34 EDT
After testing we discovered that the login failure is already counted even when
not providing a password. So the failure counter is increased the moment we type
eg. sudo ls / (and before we provided a password).

This gets even more intriguing :)
Comment 2 Dag Wieers 2006-05-31 10:14:05 EDT
After testing we discovered that the login failure is already counted even when
not providing a password. So the failure counter is increased the moment we type
eg. sudo ls / (and before we provided a password).

This gets even more intriguing :)
Comment 3 Dag Wieers 2006-05-31 10:15:53 EDT
Ok I feel silly now. I didn't noticed the customer had pam_tally configured
before pam_unix as par tof their hardening. Which obviously is wrong.

Why can't I close my own bug-report as NOTABUG ?
Comment 4 Karel Zak 2006-05-31 17:56:39 EDT
There is problem in the sudo command -- it doesn't call pam_acct_mgmt(). This
problem has been fixed in RHEL3 and RHEL4, but (now) in RHEL2.1 we fix security
or really fatal problems only. I think this bug doesn't match up with this goal
--> Sorry, closing as NEXTRELEASE.

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