Bug 659075

Summary: pam_tally2 is not capable of control authorization
Product: Red Hat Enterprise Linux 5 Reporter: John Bassford <john.bassford>
Component: pamAssignee: Tomas Mraz <tmraz>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: low    
Version: 5.5   
Target Milestone: rc   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-01 21:12:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description John Bassford 2010-12-01 20:53:59 UTC
Description of problem:
after pam_tally2 is used to control authenication and logs failed log in attempts for an account, and then the same account attempts access from another client using another authenication method (say ssh key), but that application/service still consults pam for authorization pam_tally2 is not capable of being configured to deny authorization. (ie: the pam_tally2 options of deny/unlock_time etc.. are not avialable in the auth section of pam.)

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


How reproducible:
very

Steps to Reproduce:
1.default installation of rhel5.4, yum updated to rhel5.5
2.edit system-auth, add pam_tally2 (see below)
3.from a workstation1 setup ssh key to the server, verify it works
4.from workstation2 attempt logins (password) and purpose fail (enter the wrong password)
5. verfiy pam_tally2 is logging them with pam_tally2 command.
6. after 5 failed attempts with wrong password, attempt login with ssh-key from workstation1

its here that I think the pam_tally2 has a functional bug, as my understanding of pam architecture is for any of the layers of a pam module should be able to control 1. authenication OR 2. authorization or 3, password or 4. session and or all of them. Well I agree given the purpose of pam_tally2 I don`t see any need for pam_tally2 to support the password or session layers of pam, I do like if anyone wants to use this pam module to control user accounts that exceed <x>, then pam_tally2 should also work at the account section of the pam layer.

  
Actual results:
a user account that has exceed the "deny" setting of pam_tally2 is still allow in when autheicating with an ssh key, despite sshd still consulting pam for 'account section'

Expected results:
a user should get the message your account is locked.

Additional info:

I have tested this in rhel3/4/5/6
and found, the following

rhel3
pam_tally
password works
ssh key works

rhel4
pam_tally (seemed broke...)
password doesn`t work
ssh key doesn`t work

pam_tally2
password works
ssh key doesn`t work

rhel5
pam_tally
password works
ssh key doesn`t work

pam_tally2
password works
ssh key doesn`t work

rhel6
pam_tally2
password works
ssh key doesn`t


my rhel5 system-auth file (note pam sshd file is default)

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_tally2.so onerr=fail deny=3 unlock_time
=1800
auth        required      pam_tally2.so
auth        sufficient    pam_unix.so try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so
account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so
password    requisite     pam_cracklib.so try_first_pass retry=3 minle
n=9 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 difok=2
password    sufficient    pam_unix.so md5 shadow remember=10 try_first
_pass use_authtok
password    required      pam_deny.so
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in cr
ond quiet use_uid
session     required      pam_unix.so

Comment 1 John Bassford 2010-12-01 21:00:39 UTC
oops, the first portion should read.

...
(ie: the pam_tally2 options
of deny/unlock_time etc.. are not avialable in the account section of pam.)
my apologies for the confusion.

Comment 2 Tomas Mraz 2010-12-01 21:12:46 UTC
I'm sorry but this is on purpose. If the user's passwords are being attacked with some brute-forcing attempts, it does not break security of his public/private key pairs. So there is no reason why his public key sshd authentication should be blocked.