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/
|
