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
--
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
