pam-0.79-9.1 breakage with FC4 strict policy.

[Ted Rule]

Thanks for the hint.

To avoid a complete /.autorelabel at this time, I found that a minimal
set of local tweaks to my default FC4 strict policy gave me back local
login, as in:

allow auth_chkpwd self:capability { audit_write audit_control };
allow pam_console_t console_device_t:chr_file { setattr };
allow local_login_t faillog_t:file { lock } ;
allow local_login_t self:capability { audit_control };

The ssh login problem proved to be related to SELinux, but not a policy
issue per se. I had somehow amended the sshd_config whilst the machine
was in FC3, and when it was upgraded to FC4 it failed to pick up the
critical 

	UsePAM yes

setting in the current FC4 sshd_config default settings.

As a consequence, FC4 sshd appears to assume UsePAM no, and SELinux
naturally breaks the authentication as it assumes all access to shadow_t
is via the PAM modules. Perhaps it might be worth patching sshd itself
so that the lack of an explicit UsePAM setting in the configuration file
is treated as "UsePAM yes" rather than "UsePAM no" on an SELinux capable
system?


Ted


On Mon, 2005-07-25 at 10:32 -0400, Daniel J Walsh wrote:
> 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

-- 
Ted Rule

Director, Layer3 Systems Ltd

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