Red Hat Bugzilla – Bug 217441
useradd home directory context isn't consistent with policy
Last modified: 2007-11-30 17:07:38 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.
This is likely a bug in shadow-utils. It should probably be doing a setfilecon on the homedir that its creating in create_home().
What version of shadow-utils you use? I can't reproduce it.
You need to newrole such that you have staff_u in your context before running the useradd program.
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
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).
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?
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.
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.
shadow-utils-4.0.17-10.el5 was built to solve this problem.
Is there a place I can get the rpm to give it a try or do I need to wait until the next milestone?
Sorry Linda, I thought I'd already posted this... http://people.redhat.com/jantill/useradd/
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?
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.
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
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.
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.
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.
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.
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.
Fixed in shadow-utils-4.0.17-11.el5
QE ack for RHEL5.
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.