Bug 216184

While trying a few more things on our test systems Linda found that the first
semanage is causing a policy reload.  After the first boot the system is coming
up in enforcing mode for the first time.  These two things seem to have an
effect on which label gets applied to the system.

The end of the kickstart script looks like this:

echo "Switching SELinux to MLS mode..."
lokkit -q -n --selinuxtype=mls
setenforce 0
load_policy 2>&1 | grep -v no.longer.in.policy

echo "Fixing file labels..."
fixfiles restore

echo "Please enter the password for the root account."
while ! passwd root; do :; done

while true
do
        echo
        echo "Create an administrative user account."
        Name="$(ask "Real name (First Last)")"
        Uid="$(echo "$Name" | sed 's/^\(.\).* \(.*\)$/\1\2/' | tr A-Z a-z)"
        Uid="$(ask "Userid" "$Uid")"
        if useradd -m -c "$Name" -G wheel "$Uid"
        then
                while ! passwd "$Uid"; do :; done
                chage -m 1 -M 60 -W 7 "$Uid"
                semanage login -a -s staff_u -r s0-s15:c0.c1023 "$Uid"
        else
                echo "Warning: adding user unsuccessful, please try again."
        fi

        confirm "Add more administrative users" "n" || break
done

I still have this problem.

I create a regular user with useradd.  I run restorecon on the home
directory which fixes things.  Then try to login.  The first login
attempt always fails this these AVC denies:

type=SYSCALL msg=audit(1165276913.352:779): arch=40000003 syscall=228 success=no
exit=-13 a0=6 a1=f9b00b a2=9390f30 a3=1f items=0 ppid=2930 pid=2935 auid=518
uid=0 gid=518 euid=0 suid=0 fsuid=0 egid=518 sgid=518 fsgid=518 tty=(none)
comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023
key=(null)
type=AVC msg=audit(1165276913.352:779): avc:  denied  { relabelto } for 
pid=2935 comm="sshd" name="user_u:object_r:user_home_t:SystemLow_ljkfoo"
dev=dm-1 ino=6389766 scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=user_u:object_r:user_home_t:s0 tclass=dir

type=SYSCALL msg=audit(1165276913.352:780): arch=40000003 syscall=40 success=no
exit=-13 a0=938be58 a1=1 a2=809980 a3=6 items=0 ppid=2930 pid=2935 auid=518
uid=0 gid=518 euid=0 suid=0 fsuid=0 egid=518 sgid=518 fsgid=518 tty=(none)
comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023
key=(null)
type=AVC msg=audit(1165276913.352:780): avc:  denied  { rmdir } for  pid=2935
comm="sshd" name="user_u:object_r:user_home_t:SystemLow_ljkfoo" dev=dm-1
ino=6389766 scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:polyparent_t:s0 tclass=dir

And then the ssh session terminates.  If I try to log in again, I'm
able to login but get a message:
Could not chdir to home directory /home/ljkfoo: Permission denied.
This might be a different problem related to the polyinstantiation setup.
At least on the second try it doesn't terminate my ssh session.
Oh, and the allow_polyinstantiation boolean is one.

I am trying to fix the problems with polyinstatiation and SELinux Policy 
> in MLS.
> 
> I have found that the way pam_namespace works is broken from an SELinux 
> point of view.
> 
> If I setup the /tmp directory to polyinstatiate and I log in as a 
> staff_t, I end up with /tmp mounted as staff_tmp_t instead of tmp_t.  
> This is wrong, since confined apps that I run as a user expect tmp_t.
> 
> Similarly /home/dwalsh gets mounted as staff_home_t instead of 
> staff_home_dir_t.  This causes all of the transitions to fail. 
> 
> The problem is the pam_namespace is asking the system if staff_t creates 
> a directory in tmp_t how should it be created.  The system responds 
> staff_tmp_t.  What pam_namespace should be doing is taking the directory 
> tmp_t and replacing it's MLS level with the level of the user.  That is all.


This is part of a conversation that is going on on redhat-lspp mailing list. 

I have created a patch to allow users to choose to use choose

USER - No SELinux difference.  Just polyinstatiate based on User
LEVEL - Polyinstatiate based on USER and MLS Level.  So Different roles/types
with the same Level will use the same directory
CONTEXT - Polyinstatiate based on USER, and complete context.  So one directory
for each role/type/mls the user newroles too.

Created attachment 143152 [details]
Patch to fix the problem

I don't have that yet patch but the most recent MLS policy from Dan's
people page solves the part of the problem where the first ssh attempt using
a newly created account always failed.  

Approved blocker... any idea on when this will be fixed? I need to give PM an
answer to they can target it to a RC candidate. If its ready build it into dist-5E

Fixed in pam-0.99.6.2-3.7.el5.

A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.