Red Hat Bugzilla – Bug 860440
gnome-session gets the wrong context
Last modified: 2012-10-01 12:04:47 EDT
Created attachment 617254 [details]
yum log of the update
gnome-session is getting run in the guest_u:guest_r:oddjob_mkhomedir_t:s0 context for some reason following an selinux policy upgrade. pam_oddjob_mkhomedir.so is in the session section of system-auth, but it hasn't done this before.
Here's the process tree:
LABEL PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
system_u:system_r:xdm_t:s0-s0:c0.c1023 679 ? Ssl 0:00 /usr/sbin/gdm-binary -nodaemon
system_u:system_r:xdm_t:s0-s0:c0.c1023 735 ? Sl 0:00 \_ /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
system_u:system_r:xserver_t:s0-s0:c0.c1023 745 tty1 Ss+ 0:04 \_ /usr/bin/Xorg :0 -background none -logverbose 7 -auth /var/run/gdm/auth-for-gdm-yVvNxM/database -seat seat0 -nolisten tcp vt1
system_u:system_r:xdm_t:s0-s0:c0.c1023 1013 ? Sl 0:00 \_ gdm-session-worker [pam/gdm-password]
guest_u:guest_r:oddjob_mkhomedir_t:s0 1243 ? Ssl 0:00 \_ gnome-session
I had switch selinux to permissive mode because the user couldn't login because of the AVCs this causes.
Had you setup the user to run with guest_u? If so, he is not allowed to login via gdm. If you want a confined user, which can login via GDM, then you need to setup xguest_u.
As far as I know, he's a normal user. I've never tried using the guest or confined options.
This just started happening after he did that yum update. I'm rather concerned because there's a whole class of kids with this exact same setup and it seems that unless this user is special in some way, they are all going to be unable to login as soon as they update.
What does this output?
semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023
root unconfined_u s0-s0:c0.c1023
system_u system_u s0-s0:c0.c1023
But even assuming that somehow the user is now confined in some way, why does it have oddjob_mkhomedir_t as its context? It's like that context is leaking out somehow.
Have you been playing with IPA?
Playing with? I'm using FreeIPA and there was an update for that as well in the transaction.
Ok, then it causes these issues. What does
# ls /etc/selinux/targeted/logins
IPA is set up I guess to default all users defined into IPA as guest_t, it should probably default all users to unconfined_t, or nothing at all (What I would prefer). Then the admin can set it up confined users if he wants or continue to use the system defaults.
Did this just change? It's been working up until now. I am using the FreeIPA 3 beta, so it's possibly something was changed.
The default will be changed to unconfined_u in 3.0 (it is in 3.0 rc1).
The difference is probably sssd which now properly handles SELinux user mapping.
You can probably fix this with:
ipa config-mod --ipaselinuxusermapdefault=unconfined_u:s0-s0:c0.c1023
3.0 rc1 gets fixes for SELinux user maps. We do setup guest_t because this is what agreement was originally, when SELinux user maps support was designed.
I'd leave it to Dan and Rob to decide what should we default to -- we had this discussion few months ago and were not sure that defaulting to unconfined_t is good from security perspective.
You can simply define your SELinux users map in FreeIPA to have it unconfined_t, as a workaround.
I believe the correct behaviour is to do nothing and fall back to the system defaults.
The fixes are already implemented upstream so closing the BZ as something that will be in the final release.