Bug 351201 - libuser based apps don't set selinux permissions correctly in generated homedir
Summary: libuser based apps don't set selinux permissions correctly in generated homedir
Alias: None
Product: Fedora
Classification: Fedora
Component: libuser
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F8Blocker
TreeView+ depends on / blocked
Reported: 2007-10-24 19:55 UTC by Jesse Keating
Modified: 2013-01-10 02:42 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2007-10-25 13:32:18 UTC

Attachments (Terms of Use)

Description Jesse Keating 2007-10-24 19:55:46 UTC
SELinux is preventing the gdm-binary from using potentially mislabeled files ().

Source Context:  system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context:  system_u:object_r:tmp_t:s0
Target Objects:  None [ dir ]

avc: denied { setattr } for comm=gdm-binary dev=dm-3 name=.X11-unix pid=2479
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=dir


SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "read" to (home_root_t).

Source Context:  system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
Target Context:  unconfined_u:object_r:home_root_t:s0
Target Objects:  None [ file ]

avc: denied { read } for comm=X dev=dm-3 egid=0 euid=0 exe=/usr/bin/Xorg
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=fonts.dir pid=2992
scontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 sgid=0
subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 suid=0 tclass=file
tcontext=unconfined_u:object_r:home_root_t:s0 tty=tty7 uid=0 

SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "write" to (home_root_t).

Source Context:  system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context:  system_u:object_r:home_root_t:s0
Target Objects:  None [ dir ]

avc: denied { write } for comm=gdm-binary dev=dm-3 egid=501 euid=501
exe=/usr/sbin/gdm-binary exit=-13 fsgid=501 fsuid=501 gid=501 items=0
name=jkeating pid=3021 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 sgid=501
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 suid=501 tclass=dir
tcontext=system_u:object_r:home_root_t:s0 tty=(none) uid=501 


SELinux is preventing gdm-binary (xdm_t) "link" to (kernel_t).

Source Context:  system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context:  system_u:system_r:kernel_t:s0
Target Objects:  None [ key ]

avc: denied { link } for comm=gdm-binary pid=2314
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=key

Comment 1 Jesse Keating 2007-10-24 20:17:10 UTC
These are all caused because homedirs created by system-config-users is labeling
the homedir as (home_root_t).  They should instead be (unconfied_home_dir_t).

About to test if this can be caused by adding users in firstboot.

Comment 2 Jesse Keating 2007-10-24 21:06:41 UTC
luseradd does it too, coming from libuser.

Comment 3 Jeremy Katz 2007-10-24 21:27:22 UTC
This is going to be anything using libuser to add users.  shadow-utils was
changed to explicitly set file contexts when creating the user home directory,
but libuser was never made to do that.  In the past, this worked because we had
a transition rule from home_root_t -> user_home_dir_t.  Now that the transition
rule isn't there (to support multiple roles?), the home dir isn't getting
created with the right context in apps that use libuser.

This will impact:
1) system-config-users
2) firstboot
3) Addition of users in kickstart

Comment 4 Miloslav Trmač 2007-10-25 07:53:28 UTC
Thanks, fixed in libuser-0.56.6-1.fc[89].

Jesse, are you going to add this package to Fedora 8, or should I add it to
bodhi as well?

Comment 5 Nils Philippsen 2007-10-25 11:14:44 UTC
I think this should be in F8 final, so that users created immediately after
installation get the correct SELinux contexts for their home directories.

Comment 6 Jesse Keating 2007-10-25 11:40:38 UTC
I'm going to tag it for the release.  Will need to do an install with it and
verify things look good, setting to MODIFIED.

Comment 7 Daniel Walsh 2007-10-25 13:14:00 UTC

How did you fix this?

Comment 8 Jesse Keating 2007-10-25 13:32:18 UTC
I tested with the new libuser set and now the homedirs are being created as
unconfined_u:object_r:unconfined_home_dir_t which seems correct.  Closing the
bug, but I'm sure others would still like to review the change.

Comment 9 Daniel Walsh 2007-10-25 14:04:26 UTC
Ok I tested this out and it seems to work well.

One thing we probably want to add, is the equivalent of useradd -Z which allows
you to select SELinux users.

I changed the default SELinux user and system-config-users labeled the homedirs
and all of its subdirs correctly.  Good job

Comment 10 Nils Philippsen 2007-10-25 14:15:20 UTC
(In reply to comment #9)
> One thing we probably want to add, is the equivalent of useradd -Z which allows
> you to select SELinux users.

Speaking of that, I guess certain SELinux users map to certain SELinux contexts
for the home directory -- shouldn't the -Z option be enough or isn't that a 1:1
(n:1) mapping?

Either way, is there an easy way to find out which SELinux users exist and which
is the default? It would be good if system-config-users allowed the admin to set

Comment 11 Daniel Walsh 2007-10-25 14:29:43 UTC
There is a python binding semanage that would allow you to do this.


Is a python wrapper on semanage that allows you to get this info

semanage user -l 

Is the command line interface, for this.

Comment 12 Miloslav Trmač 2007-10-25 23:58:26 UTC
libuser uses matchpathcon() to determine the context to use for each created file.

WRT SELinux users, libuser as such (as opposed to luseradd and partly to the
Python bindings) is really a "writable nss_*", ideally the libuser interfaces
should be independent from other user-related configuration.
* If a UNIX user is assigned a non-default SELinux user, will matchpathcon()
  automatically return the right file contexts for files in the user's home
* Does the UNIX user have to be created before creating the SELinux user mapping?

Comment 13 Daniel Walsh 2007-10-26 12:29:22 UTC
Yes the steps are to create a login user to SELinux user mapping.
Which from the command line is 

semanage linux -a -s SELINUX_USER USERNAME

At that point you should be able to add the user and copy the skel using

In the command line tools there is a catch 22 though.  The tools will block you
from doing the user mapping until the Linux USERNAME exists.  So it used to be 

useradd dwalsh
semanage linux -a -s xguest_u dwalsh
restorecon -R -v ~dwalsh

I hope if you call the semanage calls directly you can avoid the check for
existing username.

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