Bug 860440 - gnome-session gets the wrong context
gnome-session gets the wrong context
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: freeipa (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rob Crittenden
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-25 16:00 EDT by Samuel Sieb
Modified: 2012-10-01 12:04 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-01 12:04:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
yum log of the update (14.88 KB, text/plain)
2012-09-25 16:00 EDT, Samuel Sieb
no flags Details

  None (edit)
Description Samuel Sieb 2012-09-25 16:00:04 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
Comment 1 Samuel Sieb 2012-09-25 16:01:04 EDT
I had switch selinux to permissive mode because the user couldn't login because of the AVCs this causes.
Comment 2 Daniel Walsh 2012-09-25 16:28:15 EDT
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.
Comment 3 Samuel Sieb 2012-09-25 16:29:46 EDT
As far as I know, he's a normal user.  I've never tried using the guest or confined options.
Comment 4 Samuel Sieb 2012-09-25 16:31:53 EDT
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.
Comment 5 Daniel Walsh 2012-09-25 16:35:04 EDT
What does this output?

semanage login -l
Comment 6 Samuel Sieb 2012-09-25 18:21:52 EDT
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.
Comment 7 Daniel Walsh 2012-09-26 16:36:28 EDT
Have you been playing with IPA?
Comment 8 Samuel Sieb 2012-09-26 16:44:17 EDT
Playing with?  I'm using FreeIPA and there was an update for that as well in the transaction.
Comment 9 Miroslav Grepl 2012-09-26 16:49:24 EDT
Ok, then it causes these issues. What does

# ls /etc/selinux/targeted/logins
Comment 10 Daniel Walsh 2012-09-26 17:31:39 EDT
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.
Comment 11 Samuel Sieb 2012-09-26 17:46:23 EDT
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.
Comment 12 Rob Crittenden 2012-09-26 17:50:50 EDT
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
Comment 13 Alexander Bokovoy 2012-09-26 17:54:17 EDT
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.
Comment 14 Daniel Walsh 2012-09-27 09:39:17 EDT
I believe the correct behaviour is to do nothing and fall back to the system defaults.
Comment 15 Dmitri Pal 2012-10-01 12:04:47 EDT
The fixes are already implemented upstream so closing the BZ as something that will be in the final release.

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