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)'
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.
Could you put the machine in permissive mode to make sure I get all of the avc messages.
Fixed in selinux-policy-2.4.6-57.el5
New policy has been put in LSPP repo. We need to know if the problem is fixed. Thanks.
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.
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.
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.
Fix is in the works. Need this for LSPP.
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.
pam fixed in pam-0.99.6.2-3.21.el5. Updated policy is required to make it work.
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.
Taking this off the LSPP query.
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
Dan, see above...looks like a selinux-policy issue?
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 = "/".
To clarify, the "Login incorrect" in comment #18 really is a bad password. I should have deleted that from the comment before posting.
Ok lets try with selinux-policy-2_4_6-65_el5
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).
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.
Verified, taking off LSPP list.
Adding to the LSPP, waiting for IBM to verify.
Verified by IBM. Removing.
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