Hide Forgot
Created attachment 494244 [details] snippet from /var/audit/audit.log Description of problem: When loging in with the xguest account the following message pop-up: "Oh, no ! Something has gone wrong." The only possibility is to logout. Version-Release number of selected component (if applicable): Fedora release 15 (Lovelock) xguest-1.0.9-4.fc15.noarch selinux-policy-3.9.16-16.fc15.noarch selinux-policy-targeted-3.9.16-16.fc15.noarch libselinux-2.0.99-4.fc15.i686 gdm-3.0.0-2.fc15.i686 How reproducible: Always Steps to Reproduce: 1. On Fedora 15 install xguest 2. Log into xguest account 3. Actual results: Impossible to log, get black screen with message "Oh, no ! Something has gone wrong" Expected results: Open an xguest session Additional info: Attached is a snippet from /var/audit/audit.log Messages from audit.log which look interresting: type=USER_AUTH msg=audit(1303480936.143:203): user pid=3002 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="xguest" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=failed' type=USER_LOGIN msg=audit(1303480936.152:204): user pid=3002 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=501: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=failed' There is a workaround: setsebool -P allow_xguest_exec_content=1 and everything seems to work fine but that doesn't look good from a security point of view.
This looks like gnome-shell or one of the libraries it uses (javascript) is desperately looking for a directory that it can both write and execute. It tries /tmp, /var/tmp, ~/, /dev/shm. Do you guys know what it is doing? Is this something I just have to allow?
I would advise against a library or app needing to write and execute. That breaks the security configuration model we are trying to establish.
Well we could run gnome-shell under a different context and allow it to write and execute. but I still would like to know what it is doing.
(In reply to comment #1) > This looks like gnome-shell or one of the libraries it uses (javascript) is > desperately looking for a directory that it can both write and execute. > > It tries /tmp, /var/tmp, ~/, /dev/shm. Do you guys know what it is doing? Is > this something I just have to allow? Is the audit log snippet about gdm-session-worker is unrelated, since you've reassigned this to gnome-shell?
(In reply to comment #1) > This looks like gnome-shell or one of the libraries it uses (javascript) is > desperately looking for a directory that it can both write and execute. > > It tries /tmp, /var/tmp, ~/, /dev/shm. Do you guys know what it is doing? libffi does this IIRC, and gjs uses libffi. > Is this something I just have to allow? Basically yes. We need it for closure handling at least, and the JIT as well.
(In reply to comment #5) > (In reply to comment #1) > > This looks like gnome-shell or one of the libraries it uses (javascript) is > > desperately looking for a directory that it can both write and execute. > > > > It tries /tmp, /var/tmp, ~/, /dev/shm. Do you guys know what it is doing? > > libffi does this IIRC, and gjs uses libffi. > > > Is this something I just have to allow? > > Basically yes. We need it for closure handling at least, and the JIT as well. Are we talking executable memory segments here or executable directories?
The interpreted AVC's looks like this. type=SYSCALL msg=audit(04/22/2011 10:02:24.249:234) : arch=i386 syscall=mmap2 success=no exit=-13(Permission denied) a0=0 a1=1000 a2=5 a3=1 items=0 ppid=3051 pid=3301 auid=xguest uid=xguest gid=xguest euid=xguest suid=xguest fsuid=xguest egid=xguest sgid=xguest fsgid=xguest tty=(none) ses=7 comm=gnome-shell exe=/usr/bin/gnome-shell subj=xguest_u:xguest_r:xguest_t:s0 key=(null) type=AVC msg=audit(04/22/2011 10:02:24.249:234) : avc: denied { execute } for pid=3301 comm=gnome-shell path=/home/xguest/ffiEVuzEm (deleted) dev=tmpfs ino=44212 scontext=xguest_u:xguest_r:xguest_t:s0 tcontext=xguest_u:object_r:user_home_t:s0 tclass=file Which indicates gnome-shell trying to execute a file in the homedir named "ffiEVuzEm (deleted)" It is using the mmap2 syscall. The attach snippet above on /usr/libexec/gdm-session-worker has nothing to do with the AVC.
If gnome-shell is the only app that is going to need this access, I can turn on gnome-shell as a confined app and allow it execute privs in the homedir, or /tmp, wherever it attempts to create this mmap first.
The problem with this is how do you distinguish normal behaviour like this from malicious behaviour where you may have directory traversal + downloading and compiling a root kit.
Wouldn't it be simpler to just use a different DE for xguest?
(In reply to comment #9) > The problem with this is how do you distinguish normal behaviour like this from > malicious behaviour where you may have directory traversal + downloading and > compiling a root kit. Creating executable code at runtime for just-in-time compilation and trampolines is normal behavior for a modern runtime. If you have better methods than this approach of mapping an exectable file, that of course, could be proposed upstream for libffi. The only application *currently* in GNOME using the GJS javascript library which (uses libffi and the spidermonkey JIT), but of course that could change in the future. I don't see any GNOME Shell bug here.
I'm having a similar problem with xguest and XFCE on F15 x64. When I log in to xguest via GDM, I get a "could not load failsafe session" error, which mentions dbus, xfconfd, and xfce4-session. The only option is to click "close," which sends me back to GDM. Attached is the output from setroubleshoot.
Created attachment 503118 [details] setroubleshoot output from logging into xfce as xguest
execute # chcon -t bin_t /usr/lib64/xfce4/xfconf/xfconfd
I just checked in some changes to labeling under /usr/lib64/xfce4 to everyfile labeled as bin_t except files that end in .s0.* Which will be labeled lib_t. In Rawhide.