Latest pam/selinux-policy-strict broken?

[Stephen Smalley]

On Thu, 2004-07-29 at 16:56, W. Michael Petullo wrote:
> Login, su, gdm is hanging on my system since I upgraded to pam-0.77-52
> and selinux-policy-strict-1.15.8-3.  
> 
> It looks like the hang is occuring when the pam_unix module is executed
> as an account module.  Su/pam_unix executes unix_chkpwd, sets up a pipe
> and then reads from it.  It seems that unix_chkpwd is failing to execute
> properly and su is hanging while it tries to read from the pipe.  After a
> quick look at the code, I'm not convinced that pam_unix tests the exit
> value of unix_chkpwd properly.
> 
> Here is a strace of an su hang:
> 
> [...]
> pipe([3, 4])                            = 0
> rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x300313a8) = 4404
> waitpid(4404, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 4404
> --- SIGCHLD (Child exited) @ 0 (0) ---
> read(3, "12603:0:99999:7:-1:-1", 1023)  = 21
> read(3,
> 
> There is no problem when SELinux is not enforcing its strict policy.
> Unfortunately, I don't see any avc errors in my logs related to this.

I ran into the same bug.  Try updating your pam package from Dan Walsh's
site ftp://people.redhat.com/dwalsh/SELinux/Fedora/, as this seems to
fix the behavior for me.  I expect it will make its way into rawhide
soon.

I think I can explain the lack of avc denied messages.  There are
dontaudit rules suppressing audit of attempts to access /etc/shadow
directly by pam_unix, as it always tries to do that first.  Then, if it
fails, it falls back to running chkpwd.  In permissive mode, the attempt
to access /etc/shadow directly succeeds (since the process is uid 0), so
pam_unix doesn't end up running chkpwd at all and you don't encounter
the bug in the pam_unix code.  In enforcing mode, the attempt to access
/etc/shadow directly fails due to SELinux, but the audit is suppressed
since this is expected, and it then runs the chkpwd helper.  You then
run into the bug in pam_unix itself, which causes the failure.  So the
SELinux denial is only indirectly related to the actual bug.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency