pam-0.79-9.1 breakage with FC4 strict policy.

[Ted Rule]

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,


-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/