pam-0.79-9.1 breakage with FC4 strict policy.

[Daniel J Walsh]

Ted Rule wrote:

>I have recently updated the pam rpm on my FC4 machine from:
>
>	pam-0.79-8
>
>to
>
>	pam-0.79-9.1
>
>The machine was orginally built as FC3 running SELinux strict/enforcing,
>upgraded to FC4, "/.autorelabel"'ed, and thereafter gradually patched up
>with FC4 updates using yum. The SELinux policy is using:
>
>	selinux-policy-strict-1.23.16-6
>
>The current pam misbehaviour for a variety of authentication sequences
>is as follows:
>
>========================================
>With SELinux enforcing and pam-0.79-9.1:
>
>"su -" works Ok. ( both su-ing to root and non-root users. )
>
>"sudo" fails every time with:
>
>	sudo: pam_authenticate: System error
>
>"/bin/login" fails every time with only these messages in syslog:
>
>Jul 25 08:45:31 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr,
>System error
>Jul 25 08:45:31 topaz kernel: audit(1122277531.083:24): avc:  denied
>{ lock } for  pid=5704 comm="login" name="btmp" dev=hda7 ino=339558
>scontext=system_u:system_r:local_login_t
>tcontext=system_u:object_r:faillog_t tclass=file
>
>"ssh localhost" fails every time with:
>
>Jul 25 08:48:31 topaz sshd[14927]: error: Could not get shadow
>information for ejtr
>Jul 25 08:48:31 topaz sshd[14927]: Failed password for ejtr from
>127.0.0.1 port 50117 ssh2
>
>=========================================
>With SELinux permissive and pam-0.79-9.1:
>
>"su -" works Ok. ( both su-ing to root and non-root users. )
>
>"sudo" fails 1st time with:
>
>	sudo: pam_authenticate: System error
>
>and then succeeds 2nd time - but still asks for password. On the 3rd
>attempt it caches the authentication from the 2nd attempt and works Ok.
>
>
>"/bin/login" appears to fail twice and then succeed.
>
>Jul 25 08:53:07 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr,
>System error
>Jul 25 08:53:07 topaz kernel: audit(1122277987.276:26): avc:  denied
>{ lock } for  pid=5767 comm="login" name="btmp" dev=hda7 ino=339558
>scontext=system_u:system_r:local_login_t
>tcontext=system_u:object_r:faillog_t tclass=file
>Jul 25 08:53:11 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr,
>System error
>Jul 25 08:53:11 topaz kernel: audit(1122277991.339:27): avc:  denied
>{ lock } for  pid=10278 comm="login" name="btmp" dev=hda7 ino=339558
>scontext=system_u:system_r:local_login_t
>tcontext=system_u:object_r:faillog_t tclass=file
>Jul 25 08:53:15 topaz login(pam_unix)[10621]: session opened for user
>ejtr by (uid=0)
>Jul 25 08:53:15 topaz  -- ejtr[10621]: LOGIN ON tty2 BY ejtr
>Jul 25 08:53:19 topaz login(pam_unix)[10621]: session closed for user
>ejtr
>Jul 25 08:53:25 topaz login(pam_unix)[11502]: session opened for user
>ejtr by (uid=0)
>Jul 25 08:53:25 topaz  -- ejtr[11502]: LOGIN ON tty2 BY ejtr
>Jul 25 08:53:27 topaz login(pam_unix)[11502]: session closed for user
>ejtr
>
>
>"ssh localhost" works 1st time.
>
>===============================================
>
>
>When I saw the "shadow" error on sshd, I tried adding some "debug" to
>SELinux policy to double check that the correct domain was trying to
>read shadow_t. That proved to be a red-herring, as did tracking the lock
>access denial on /var/log/btmp.
>
>I've checked SELinux file_contexts on the pam installed files - seems
>Ok. I've tried downgrading pam to 0.79-8 and back to 0.79-9.1 again. The
>system consistently works every time with 0.79-8 and misbehaves every
>time with 0.79-9.1
>
>Amongst the trail of debugging, I've found a couple of pam errors which
>are seemingly unrelated to the overall failure, but probably need
>fixing:
>
>This:
>
>	allow crond_t self:capability { audit_control } ;
>
>seems to be needed to allow per-user crontab's to audit correctly.
>
>There seems to be some inconsistency in the use and non-use of
>pam_loginuid.so and pam_selinux.so in /etc/pam.d/XXXX as between 
>
>	/etc/pam.d/su
>	/etc/pam.d/sudo
>	/etc/pam.d/login
>	/etc/pam.d/gdm
>	/etc/pam.d/sshd
>
>I would have thought that most, if not all, of the pam.d configurations
>should have pam_loginuid.so and pam_selinux.so references, but I could
>so easily be wrong about this.
>
>I also noticed that the FC3 -> FC4 upgrade process failed to
>automatically install the "audit" rpm. I manually added it via yum
>whilst tracking the pam problem, but the lack of the auditd service also
>seems to be a red-herring. I currently have it installed but
>chkconfig'ed off - mainly so as to ensure all the logs are in one place
>for ease of debugging.
>
>I've tried temporarily disabling various clauses in /etc/pam.d/login -
>such as pam_console - to try and isolate the issue, but I haven't had
>much luck with that either. With "debug" enabled on the pam_stack.so
>entry in /etc/pam.d/login, it seems that "system-auth" always returns
>SUCCESS, which seems to eliminate most of pam as a source of error. 
>
>Can anyone throw any light on the problem or give me some other ideas
>for debugging the issue?
>
>
>Thanks,
>
>
>  
>
All of these fixes are in the latest policy available for FC4

--