Bug 217441 - useradd home directory context isn't consistent with policy
useradd home directory context isn't consistent with policy
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: shadow-utils (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: James Antill
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-27 17:02 EST by Linda Knippers
Modified: 2007-11-30 17:07 EST (History)
7 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:56:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to change the context of a made homedir to matchpathcon() result (1.42 KB, patch)
2006-11-29 21:36 EST, James Antill
no flags Details | Diff

  None (edit)
Description Linda Knippers 2006-11-27 17:02:32 EST
Description of problem:
When a user account is created and the -m option is used to create
the user's home directory, the user part of the SELinux context
is the same as the user who created the account, rather than being
the selinux user for the new user.  A restorecon will change it to
what I would normally expect it to be.

Version-Release number of selected component (if applicable):
RHEL5 Beta 2 with these policy RPMs from Dan's people page:

selinux-policy-devel-2.4.5-3.el5
checkpolicy-1.30.12-1
policycoreutils-1.33.2-2.el5
policycoreutils-newrole-1.33.2-2.el5
selinux-policy-mls-2.4.5-3.el5
selinux-policy-2.4.5-3.el5
selinux-policy-targeted-2.4.5-3.el5


How reproducible:


Steps to Reproduce:
1.run "useradd -m <login>"
2.run "ls -lZ /home/<login>" to get the context
3.run "restorecon -R -v ~<login>"
4. run "ls -lZ /home/<login>" again to get the context
  
Actual results:

After the first 'ls', the context is:
    staff_u:object_r:user_home_dir_t:SystemLow
After the restorecon, the context is:
    user_u:object_r:user_home_dir_t:SystemLow-s15:c0.c1023

Expected results:

I would expect that useradd would create a home directory with
the context that the policy would restore with a restorecon.  
For example, user_u with user_home_dir_t instead of staff_u with
user_home_dir_t.  

I'm not sure why the restorecon changed the directory to be ranged.  
There isn't an entry for this login in the seusers file and the default 
user is "__default__:user_u:s0".

Additional info:

I picked "selinux-policy" for the component so Dan would see the 
bugzilla although the fix is probably in useradd.
Comment 1 Steve Grubb 2006-11-28 09:04:23 EST
This is likely a bug in shadow-utils. It should probably be doing a setfilecon
on the homedir that its creating in create_home().
Comment 2 Peter Vrabec 2006-11-29 16:47:36 EST
What version of shadow-utils you use? I can't reproduce it.
Comment 3 Steve Grubb 2006-11-29 17:00:29 EST
You need to newrole such that you have staff_u in your context before running
the useradd program.
Comment 4 Linda Knippers 2006-11-29 17:04:26 EST
I'm running the shadow-utils from beta2 shadow-utils-4.0.17-7.el5.

My system was installed using the kickstart script that we're using for
the lspp project, described here:
https://www.redhat.com/archives/redhat-lspp/2006-November/msg00042.html
You need to be running the MLS policy.

I just reproduced it again:

[ljk@kipper ~]$ /bin/su -
Password:
[root@kipper ~]# useradd -m normalljk2
[root@kipper ~]# ls -lZ /home/normalljk
[root@kipper ~]# ls -ldZ /home/normalljk2
drwx------  normalljk2 normalljk2 staff_u:object_r:home_root_t:SystemLow
/home/normalljk2
[root@kipper ~]# restorecon -R -v ~normalljk2
restorecon reset /home/normalljk2 context
staff_u:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0-s15:c0.c1023
[root@kipper ~]# ls -ldZ /home/normalljk2
drwx------  normalljk2 normalljk2
user_u:object_r:user_home_dir_t:SystemLow-SystemHigh /home/normalljk2
Comment 5 James Antill 2006-11-29 21:36:39 EST
Created attachment 142460 [details]
Patch to change the context of a made  homedir to matchpathcon() result

 This should fix the problem. I haven't tested on MLS, but it's so simple it's
hard to believe there's a bug there.

 Note that if it fails it just continues, as this is what chown/chmod do in the
same function (and in non-MLS that's almost certainly the right thing to do as
well).
Comment 6 Daniel Walsh 2006-11-30 08:59:06 EST
Does it generate any avc messages?  Could you create an init script that does a
useradd, relabel it initrc_exec_t and then service start it, to see if any avc
messages are generated?
Comment 7 Steve Grubb 2006-11-30 11:03:08 EST
This patch has "extra" fixing that is not strictly needed. But otherwise looks
exactly as expected. Looks safe to build into rawhide for testing purposes.
Comment 8 Linda Knippers 2006-11-30 12:29:05 EST
I'm not sure who Dan was asking and whether he was looking for something
before or after the patch but I looked at the audit logs from when I
did my experiment above (no patch) and I have no avc denies from useradd.
I get lots of avc granted messages for setfscreate.
Comment 9 Steve Grubb 2006-11-30 15:42:54 EST
shadow-utils-4.0.17-10.el5 was built to solve this problem.
Comment 10 Linda Knippers 2006-11-30 17:34:43 EST
Is there a place I can get the rpm to give it a try or do I need to wait
until the next milestone?
Comment 11 James Antill 2006-11-30 17:42:30 EST
 Sorry Linda, I thought I'd already posted this...

http://people.redhat.com/jantill/useradd/
Comment 12 Linda Knippers 2006-11-30 18:13:03 EST
Thanks James.  

I got a warning when I installed the rpm that it had moved /etc/login.defs but
I ignored so I ended up without a file.  useradd silently fails in that case,
but I found this message in /var/log/secure:
Nov 30 17:47:52 kipper useradd[2094]: cannot open login definitions
/etc/login.defs [No such file or directory]
I got no messages from the command though so that seems weird, but 
probably unrelated to these changes.

Anyway, I fixed my system so useadd works but I'm still seeing the same
behavior regarding the context of the new home directory.  I'm logged
in as a non-root user, do an su, then a newrole to become sysadm_r, then
do this:

[root@kipper ~]# useradd -m antill
[root@kipper ~]# ls -ldZ /home/antill
drwx------  antill antill staff_u:object_r:user_home_dir_t:SystemLow /home/antill
[root@kipper ~]# restorecon -R -v ~antill
restorecon reset /home/antill context
staff_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_dir_t:s0-s15:c0.c1023
[root@kipper ~]# ls -ldZ /home/antill
drwx------  antill antill user_u:object_r:user_home_dir_t:SystemLow-SystemHigh
/home/antill

Notice the context changes from staff_u to user_u and from SystemLow to
SystemLow-SystemHigh.  The type field stays the same and looks right.
user_u looks right after the restorecon but I don't know why it ranged 
the directory.   The default user in seusers is:
__default__:user_u:s0

So I think the net result is that setting the type part of the context
was fixed but not the user field, and I don't know why restorecon
ranged the directory, but that almost seems like a separate issue.
Are all home directories supposed to be ranged?
Comment 13 Linda Knippers 2006-11-30 18:15:25 EST
I should add that I did the above with the namespace support turned off
in /etc/security/namespace.conf.  I can't do a newrole with the latest
newrole rpm when its enabled but that's a separate issue too.  Just
wanted to point this out in case you try it and get different results.
Comment 14 James Antill 2006-11-30 22:35:38 EST
 Ok, so without the patch it was:

staff_u:object_r:home_root_t:s0

...and after matchpathcon() it is:

staff_u:object_r:user_home_dir_t:s0

...which is better. But after restorecon (in either case) it is:

user_u:object_r:user_home_dir_t:s0-s15:c0.c1023

...so I'm guessing either restorecon isn't doing just a matchpathcon(), or there
is some policy difference between the context useradd runs in and the context
restorecon runs in. Can you provide the output of:

 matchpathcon /home
 matchpathcon /home/foo
Comment 15 Linda Knippers 2006-12-01 12:18:14 EST
Your summary is correct.  This is what I see from matchpathcon.
/home   system_u:object_r:home_root_t:SystemLow-SystemHigh
/home/foo       staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh
/home/antcill   user_u:object_r:user_home_dir_t:SystemLow-SystemHigh

Your "foo" request was probably just an example but I actually had created a
foo account earlier and had done as semanage on it.  Since there's a listing for
"foo" in seusers "foo:staff_u:s0-s15:c0.c1023", the matchpathcon
output for it looks reasonable.  I didn't do an semanage for the
antcill account.
Comment 16 Stephen Smalley 2006-12-01 14:19:48 EST
A couple comments:
1) I don't believe that useradd can do the right thing here in general for
labeling of home directories, because you have to first add the Linux user id
via useradd, then use semanage to map the Linux user id to a SELinux user and
range, and it isn't until that second step that SELinux is going to know how to
label that home directory (and you have to apply restorecon after that point). 
Sure you can handle the case where you just are defaulting to user_u, but that
is just one case.  So a separate restorecon of the home directory is always
going to be necessary unless of course one creates a new UI that encapsulates
the entire sequence for adding a user and defining his authorized role set
(SELinux user) and range.
2) The home directory level wouldn't come from the user's clearance anyway - it
is just coming from homedir_template in policy and is always the same for
everyone.  Then the home directory gets polyinstantiated by pam_namespace to
contain multiple single level directories.  So if you want the top-level
container directory (the one that just holds the per-level directories) to be
SystemLow, just change homedir_template and rebuild your policy.  I suspect the
range comes from the old TCS approach of using ranged directories to provide
"multi-level" directories in the absence of polyinstantiation.
Comment 17 Linda Knippers 2006-12-01 14:30:12 EST
I don't understand why it doesn't/can't work in the default case.  Makes
me wonder what the behavior is right now with the strict policy since more
than just the level isnt' right.   

It would be nice if we could create the selinux user first and then tell
useradd to associate the linux user with it, or to use the default selinux
user info.

And if I could get polyinstantiation to work I'd be a real happy camper.
Comment 18 Stephen Smalley 2006-12-01 15:15:02 EST
The same issue exists in strict policy, and is even described in SELinux
documentation.  Adding Linux users is a separate action from authorizing them
for SELinux contexts, and labeling of their home directories can only occur
after the latter.  We could drop the requirement from semanage (seobject.py)
that the Linux user already be defined, but that was intended to prevent
mistakes (e.g. typo in the username) - it is a validity check on the input.
Comment 19 Karl MacMillan 2006-12-01 15:19:37 EST
Optionally dropping the check for a linux user may make sense - it would help
useradd and perhaps sharing mappings between systems.

With that change useradd could make the correct semanage call first and then
create the user. Of course to be truly useful useradd would need flags to set
the roles.
Comment 20 Daniel Walsh 2007-01-05 16:50:33 EST
Fixed in shadow-utils-4.0.17-11.el5
Comment 21 Jay Turner 2007-01-10 22:53:34 EST
QE ack for RHEL5.
Comment 22 RHEL Product and Program Management 2007-02-07 19:56:46 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.