Bug 659075 - pam_tally2 is not capable of control authorization
Summary: pam_tally2 is not capable of control authorization
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam
Version: 5.5
Hardware: i386
OS: Linux
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
Depends On:
TreeView+ depends on / blocked
Reported: 2010-12-01 20:53 UTC by John Bassford
Modified: 2010-12-01 21:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-01 21:12:46 UTC
Target Upstream Version:

Attachments (Terms of Use)

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:

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

password works
ssh key works

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

password works
ssh key doesn`t work

password works
ssh key doesn`t work

password works
ssh key doesn`t work

password works
ssh key doesn`t

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

# 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
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.

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