Bug 236316 - LSPP: Unable to change expired password on ssh login
LSPP: Unable to change expired password on ssh login
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam (Show other bugs)
5.0
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Tomas Mraz
David Lawrence
: OtherQA
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-04-12 22:22 EDT by Matt Anderson
Modified: 2009-06-19 12:40 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHSA-2007-0555
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 10:40:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
All of the audit.log entries during the login and passwd reset process (7.82 KB, text/plain)
2007-04-13 14:22 EDT, Matt Anderson
no flags Details
Proposed patch (65.93 KB, patch)
2007-04-22 09:17 EDT, Tomas Mraz
no flags Details | Diff

  None (edit)
Description Matt Anderson 2007-04-12 22:22:01 EDT
Description of problem:
When a user account password expires the current configuration has PAM force the
user to set a new password on login.  This process is started over an ssh
session, but errors along the way and the password is never reset.

Version-Release number of selected component (if applicable):
selinux-policy-2.4.6-45.el5

How reproducible:
Everytime

Steps to Reproduce:
1. Set the password on an account to expire
2. ssh into the system on that account
3. Attempt to set a new password for the account
  
Actual results:
Connection Closed by $host is returned by ssh after what appears to the client
to be a successful password reset.  When re-connecting the old password is still
the current password so the process is repeated.

Expected results:
The user's password should be updated and they should be allowed into their session.

Additional info:
This is what I think are the relevant AVCs

--  Here the session comes in, and the password is found to be expired

type=USER_AUTH msg=audit(1176429742.088:8671): user pid=5602 uid=0
auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM:
authentication acct=eal2 : exe="/usr/sbin/sshd" (hostname=cert-i1.zko.hp.com,
addr=16.116.11.168, terminal=ssh res=success)'
type=USER_ACCT msg=audit(1176429742.107:8672): user pid=5602 uid=0
auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM:
accounting acct=eal2 : exe="/usr/sbin/sshd" (hostname=cert-i1.zko.hp.com,
addr=16.116.11.168, terminal=ssh res=failed)'

-- these are the audits that occur when the user is updating their password

type=AVC msg=audit(1176429780.425:8673): avc:  denied  { search } for  pid=5602
comm="sshd" name="cracklib" dev=dm-0 ino=2131789
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:crack_db_t:s0 tclass=dir
type=SYSCALL msg=audit(1176429780.425:8673): arch=40000003 syscall=5 success=no
exit=-13 a0=bfa458f8 a1=0 a2=1b6 a3=904c700 items=0 ppid=5596 pid=5602
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="sshd" exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 key=(null)
type=USER_ERR msg=audit(1176429780.441:8674): user pid=5596 uid=0
auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM:
bad_ident acct=? : exe="/usr/sbin/sshd" (hostname=cert-i1.zko.hp.com,
addr=16.116.11.168, terminal=ssh res=failed)'
Comment 1 RHEL Product and Program Management 2007-04-13 06:43:41 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 2 Daniel Walsh 2007-04-13 08:58:47 EDT
Could you put the machine in permissive mode to make sure I get all of the avc
messages.
Comment 3 Daniel Walsh 2007-04-13 09:46:16 EDT
Fixed in selinux-policy-2.4.6-57.el5
Comment 5 Daniel Walsh 2007-04-13 10:10:06 EDT
Fixed in selinux-policy-2.4.6-57.el5
Comment 7 Steve Grubb 2007-04-13 11:23:07 EDT
New policy has been put in LSPP repo. We need to know if the problem is fixed.
Thanks.
Comment 8 Matt Anderson 2007-04-13 14:22:33 EDT
Created attachment 152572 [details]
All of the audit.log entries during the login and passwd reset process

I updated to the .57 policy and still saw the problem.	I set the system to
Permissive and these are the AVCs:

type=AVC msg=audit(1176487654.815:9160): avc:  denied  { write } for  pid=6570
comm="sshd" name=".pwd.lock" dev=dm-0 ino=983286
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:shadow_t:s0 tclass=file
type=AVC msg=audit(1176487654.815:9161): avc:  denied  { lock } for  pid=6570
comm="sshd" name=".pwd.lock" dev=dm-0 ino=983286
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:shadow_t:s0 tclass=file
type=AVC msg=audit(1176487654.822:9162): avc:  denied  { write } for  pid=6570
comm="sshd" name="security" dev=dm-0 ino=983249
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=dir
type=AVC msg=audit(1176487654.822:9162): avc:  denied  { add_name } for 
pid=6570 comm="sshd" name="nopasswd"
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=dir
type=AVC msg=audit(1176487654.822:9162): avc:  denied  { create } for  pid=6570
comm="sshd" name="nopasswd" scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file
type=AVC msg=audit(1176487654.822:9163): avc:  denied  { setattr } for 
pid=6570 comm="sshd" name="nopasswd" dev=dm-0 ino=983862
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file
type=AVC msg=audit(1176487654.823:9164): avc:  denied  { write } for  pid=6570
comm="sshd" name="nopasswd" dev=dm-0 ino=983862
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file
type=AVC msg=audit(1176487654.824:9165): avc:  denied  { remove_name } for 
pid=6570 comm="sshd" name="nopasswd" dev=dm-0 ino=983862
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=dir
type=AVC msg=audit(1176487654.824:9165): avc:  denied  { rename } for  pid=6570
comm="sshd" name="nopasswd" dev=dm-0 ino=983862
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file
type=AVC msg=audit(1176487654.824:9165): avc:  denied  { unlink } for  pid=6570
comm="sshd" name="opasswd" dev=dm-0 ino=983887
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file
type=AVC msg=audit(1176487654.825:9166): avc:  denied  { create } for  pid=6570
comm="sshd" name="nshadow" scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:shadow_t:s0 tclass=file
type=AVC msg=audit(1176487654.825:9167): avc:  denied  { setattr } for 
pid=6570 comm="sshd" name="nshadow" dev=dm-0 ino=983887
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:shadow_t:s0 tclass=file
type=AVC msg=audit(1176487654.825:9168): avc:  denied  { rename } for  pid=6570
comm="sshd" name="nshadow" dev=dm-0 ino=983887
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:shadow_t:s0 tclass=file
type=AVC msg=audit(1176487654.825:9168): avc:  denied  { unlink } for  pid=6570
comm="sshd" name="shadow" dev=dm-0 ino=983888
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:shadow_t:s0 tclass=file


Attached is the entire audit trail.
Comment 9 Daniel Walsh 2007-04-13 14:54:37 EDT
This turns out to be a pam problem.  Pam needs to exec a helper application in
order to do change an expired passwd.  

Currently pam tries to write changes to the shadow file itself, which is not
allowed.  So we need to treat this similarly to the way we check passwords now.
 Except we need to use a separate non-setuid application to change the passwd.
Comment 10 Tomas Mraz 2007-04-13 16:12:26 EDT
Writing changes to the /etc/shadow is already included in the unix_chkpwd helper
binary. What makes the password change not to work is a (recent?) change which
confines sshd_t to not allow practically any file manipulations in /etc as seen
from the above audit log. That will require non-trivial rewrite of the password
change code in pam_unix.
Comment 11 George C. Wilson 2007-04-16 16:30:01 EDT
Fix is in the works. Need this for LSPP.
Comment 12 Tomas Mraz 2007-04-22 09:17:22 EDT
Created attachment 153253 [details]
Proposed  patch

This is a lightly tested patch which delegates all the writes in /etc including
/etc/shadow necessary for password change to a new unix_update helper.

Following SELinux allow rules are necessary however asserts prevent the
shadow_t rules:
allow system_chkpwd_t etc_t:dir { add_name remove_name write };
allow system_chkpwd_t etc_t:file { create rename setattr unlink write };
allow system_chkpwd_t shadow_t:file { create setattr unlink write };
allow system_chkpwd_t self:process setfscreate;

Note that the patch is pretty invasive so thorough regression testing of
pam_unix module especially regarding password change is required.
Comment 13 Tomas Mraz 2007-04-24 05:52:37 EDT
pam fixed in pam-0.99.6.2-3.21.el5. Updated policy is required to make it work.
Comment 14 Matt Anderson 2007-04-24 12:51:54 EDT
I loaded pam-0.99.6.2-3.21.el5 and selinux-policy-2.4.6-64.el5 on my system and
thinks look good.

I connected with an aged password and was prompted to change my password.  I
attempted to change to my previous password with is disallowed in the current
configuration.  The session complained (three times) but did not drop my ssh
session.  I then changed my password to one that was suggested by pam_passwdqc
and was greeted with my shell prompt.

From a functional perspective this looks fixed.  I have been looking over the
code in unix-update-helper.patch today and will continue to review it.
Comment 15 Steve Grubb 2007-04-24 14:00:35 EDT
Taking this off the LSPP query.
Comment 16 George C. Wilson 2007-04-24 19:52:59 EDT
I did a fresh install of all the latest bits less the newest vixie cron on a
ppc64 LPAR. In the course of the installation, I created a test user. After the
reboot, I logged into the console as the test user. Then I did a /bin/su -. I
got prompted for the password, entered it, and got "/bin/su: incorrect
password." Two other testers here have seen similar behavior. I'm going to
reinstall anew to make sure I didn't fat finger something. To be clear, this is
selinux-policy-2.4.6-64 and pam-0.99.6.2-3.21.

Below is Camilo's note:

Hi Folks,



I am getting password incorrect with my new installed machine... :-( but

if I put in permissive mode, everything sounds fine.

I think that's a pam issue... Is anybody getting that problem with the

new ks?




my audit.log:

msg='PAM: accounting acct=root : exe="/bin/su" (hostname=?, addr=?,

terminal=pts/1 res=failed)'

type=USER_AUTH msg=audit(1177436864.287:323): user pid=2058 uid=500

auid=500 subj=staff_u:staff_r:staff_su_t:s0-s15:c0.c1023 msg='PAM:

authentication acct=root : exe="/bin/su" (hostname=?, addr=?,

terminal=pts/1 res=success)'

type=AVC msg=audit(1177436864.296:324): avc:  denied  { execute } for

pid=2060 comm="su" name="unix_update" dev=dm-0 ino=227086

scontext=staff_u:staff_r:staff_su_t:s0-s15:c0.c1023

tcontext=system_u:object_r:updpwd_exec_t:s0 tclass=file

type=SYSCALL msg=audit(1177436864.296:324): arch=14 syscall=11

success=no exit=-13 a0=7b6a980 a1=f952f230 a2=7b70660 a3=fefefeff

items=0 ppid=2058 pid=2060 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0

egid=500 sgid=500 fsgid=500 tty=pts1 comm="su" exe="/bin/su"

subj=staff_u:staff_r:staff_su_t:s0-s15:c0.c1023 key=(null)

type=USER_ACCT msg=audit(1177436864.299:325): user pid=2058 uid=500

auid=500 subj=staff_u:staff_r:staff_su_t:s0-s15:c0.c1023 msg='PAM:

accounting acct=root : exe="/bin/su" (hostname=?, addr=?, terminal=pts/1

res=failed)'

type=USER_AUTH msg=audit(1177436879.212:326): user pid=2061 uid=500

auid=500 subj=staff_u:staff_r:staff_su_t:s0-s15:c0.c1023 msg='PAM:

authentication acct=root : exe="/bin/su" (hostname=?, addr=?,

terminal=pts/1 res=failed)'



in /var/log/messages:

Apr 24 11:43:19 zaphod xinetd[1521]: Started working: 1 available

service

Apr 24 12:20:22 zaphod sshd[1705]: Connection closed by 9.18.250.25

Apr 24 12:20:55 zaphod sshd[1706]: Accepted keyboard-interactive/pam for

ealuser from 9.18.250.25 port 47663 ssh2

Apr 24 12:25:09 zaphod sshd[1969]: Accepted keyboard-interactive/pam for

ealuser from 9.18.250.25 port 47670 ssh2

Apr 24 12:44:01 zaphod sshd[2013]: Accepted keyboard-interactive/pam for

ealuser from 9.18.250.25 port 49344 ssh2



Regards



Camilo
Comment 17 Steve Grubb 2007-04-24 19:57:37 EDT
Dan, see above...looks like a selinux-policy issue?
Comment 18 George C. Wilson 2007-04-25 00:08:37 EDT
Confirmed this is real with yet another install (and picked up the new cron as
well). Also, logging in as root shows a /root not found message. But you can cd
/root once you're in. Here's the login (hmm, kernel version grammar is bad - not
that I have room talk - but never paid attention to it before):

Red Hat Enterprise Linux Server release 5 (Tikanga)
Kernel 2.6.18-8.1.1.lspp.77.el5 on an ppc64

nachos.ltc.austin.ibm.com login: root
Password:
Login incorrect

login: root
Password:
Default Security Context root:sysadm_r:sysadm_t:SystemLow-SystemHigh

Would you like to enter a different role or level? [n] n
No directory /root!
Logging in with home = "/".
Comment 19 George C. Wilson 2007-04-25 00:37:43 EDT
To clarify, the "Login incorrect" in comment #18 really is a bad password. I
should have deleted that from the comment before posting.
Comment 20 Daniel Walsh 2007-04-25 10:59:35 EDT
Ok lets try with selinux-policy-2_4_6-65_el5
Comment 21 Klaus Weidner 2007-04-25 19:34:56 EDT
How about restricting the /sbin/unix_update binary to be root executable only
(mode 700), since it runs with elevated privileges through the _exec_t, and if I
understand it right it won't work anyway if run without DAC root? That way you
don't need to analyze the policy to verify that it can't break anything. (This
is mainly an issue for MLS configurations).
Comment 22 Matt Anderson 2007-04-26 12:44:09 EDT
With selinux-policy 2.4.6-67.el5 and pam 0.99.6.2-3.22.el5 I am able to change
an aged password during the login phase of an ssh session.
Comment 23 Irina Boverman 2007-04-26 16:31:04 EDT
Verified, taking off LSPP list.
Comment 24 Irina Boverman 2007-04-26 16:41:23 EDT
Adding to the LSPP, waiting for IBM to verify.
Comment 25 Steve Grubb 2007-04-26 17:01:05 EDT
Verified by IBM. Removing.
Comment 29 errata-xmlrpc 2007-11-07 10:40:32 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-0555.html

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