Bug 216184 - initial pam logins to a polyinstantiated home directory fail
initial pam logins to a polyinstantiated home directory fail
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-17 12:28 EST by Matt Anderson
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RC
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-07 19:35:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to fix the problem (8.51 KB, text/x-patch)
2006-12-08 10:11 EST, Daniel Walsh
no flags Details

  None (edit)
Description Matt Anderson 2006-11-17 12:28:06 EST
Description of problem:
When logging into a user account that is setup for a polyinstantiation the first
attempt to login fails with pam_namespace unable to create the user's home
directory.

How reproducible:
First time, everytime

Steps to Reproduce:
1. Create an account that has a home dir polyinstantiated
2. Connect to the system so that pam_namespace is used in the authentication
process to create the polyinstantiated directory
3. Get denied after successfully authenticating
4. Connect again and it will authenticate correctly, but the directory will not
be owned by the user
  
Actual results:
The directory is created, but its owned by root, and the selinux label is incorrect.

Expected results:
The directory should be owned by the user, and should have a label associated
with that user.

Additional info:
An allow rule like -
allow sshd_t staff_home_t:dir { getattr setattr relabelto };

Is needed, but for each _home_t type and from each possible entry point into the
system.
Comment 1 Matt Anderson 2006-11-20 17:44:24 EST
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
Comment 3 Linda Knippers 2006-12-04 19:17:20 EST
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.
Comment 4 Daniel Walsh 2006-12-08 10:08:53 EST
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.
Comment 5 Daniel Walsh 2006-12-08 10:11:47 EST
Created attachment 143152 [details]
Patch to fix the problem
Comment 6 Linda Knippers 2006-12-08 14:33:18 EST
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.  
Comment 7 Pete Graner 2006-12-13 22:19:46 EST
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
Comment 8 Tomas Mraz 2006-12-14 05:20:58 EST
Fixed in pam-0.99.6.2-3.7.el5.
Comment 9 RHEL Product and Program Management 2007-02-07 19:35:40 EST
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.

Note You need to log in before you can comment on or make changes to this bug.