Bug 855070

Summary: policy prevents xauth from accessing urandom chr_file
Product: [Fedora] Fedora Reporter: Antoine Martin <antoine>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 17CC: dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-22 00:00:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Antoine Martin 2012-09-06 15:39:03 UTC
Description of problem: I create a number of virtual displays (either with Xvfb or with Xdummy) and when winswitch tries to set the xauth tokens for those displays, I get an selinux alert.


Version-Release number of selected component (if applicable): 
selinux-policy-targeted-3.10.0-146.fc17.noarch
selinux-policy-3.10.0-146.fc17.noarch

How reproducible: always.


Steps to Reproduce:
1. Start winswitch
2. Start an xpra session of any kind

  
Actual results:
session starts but the alert is issued.


Expected results:
session starts without alert.


Additional info:
This is pretty much what winswitch does when starting new xpra sessions:
* Xvfb +extension Composite -screen 0 3840x2560x24+32 -nolisten tcp -noreset -auth $XAUTHORITY :62
* /usr/bin/xauth add :62 MIT-MAGIC-COOKIE-1 9f5d3652e5ca73387e6913765eb1d96f
Obviously, the display number changes, and the xauth token is randomly pre-generated by winswitch.
Strangely enough, if I run those two commands from the shell, I don't get the alert. I have no idea why xauth behaves differently when ran from winswitch but at the end of the day, if xauth needs /dev/urandom, it should have it.

Comment 1 Antoine Martin 2012-09-10 05:36:19 UTC
I grabbed the exact command line used with xauth by doing:

mv /usr/bin/xauth /usr/bin/xauth.real
cat << EOF > /usr/bin/xauth

#!/bin/bash

echo "" >> /tmp/xauth.log
date >> /tmp/xauth.log
echo "xauth $@"  >> /tmp/xauth.log
echo "PPID=$PPID"  >> /tmp/xauth.log
echo "PID=$$"  >> /tmp/xauth.log
echo "PP=`ps -ef | grep $PPID | grep -v grep`"  >> /tmp/xauth.log

/usr/bin/xauth.real "$@"

And this is what is run:

Mon Sep 10 12:26:07 ICT 2012
xauth add :61 MIT-MAGIC-COOKIE-1 3a36497f58b026cd0e002585e3e17252
PPID=11242
PID=11244
PP=antoine  11242     1  0 12:26 ?        00:00:00 /bin/python /usr/bin/xpra --bind-tcp=127.0.0.1:15062 --password-file=/home/antoine/.winswitch/server/sessions/61/session.pass --no-daemon --no-pulseaudio start :61
antoine  11243 11242  0 12:26 ?        00:00:00 Xvfb-for-Xpra-:61 +extension Composite -screen 0 3840x2560x24+32 -nolisten tcp -noreset -auth /var/run/gdm/auth-for-antoine-TLenrZ/database :61
antoine  11244 11242  0 12:26 ?        00:00:00 /bin/bash /usr/bin/xauth add :61 MIT-MAGIC-COOKIE-1 3a36497f58b026cd0e002585e3e17252

Comment 2 Miroslav Grepl 2012-09-10 05:53:45 UTC
Fixed in selinux-policy-3.10.0-149.fc17

Comment 3 Fedora Update System 2012-09-17 12:14:31 UTC
selinux-policy-3.10.0-149.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-149.fc17

Comment 4 Fedora Update System 2012-09-19 02:56:05 UTC
Package selinux-policy-3.10.0-149.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-149.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14301/selinux-policy-3.10.0-149.fc17
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2012-09-22 00:00:11 UTC
selinux-policy-3.10.0-149.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.