Bug 215343

QE ack for RHEL5.

Its unclear why VNC is showing errors if your setup to use SDL, unless perhaps
you're using both. We need more info to debug this. Please create attachments
containing

 - The guest config file from /etc/xen
 - /var/log/xend.log
 - /var/log/xend-debug.log
 - The most recent of the 'qemu-dm-*.log' files from /var/log/xen

SDL just worked fine for me without having to restart the guest -- please
provide the guest config as well as how you're logging in

I'm completely unable to reproduce this here.  Please provide the logs from the
failure as well as the config as I originally asked for. 

Created attachment 144486 [details]
Failing domain config file from intel

Created attachment 144487 [details]
Xend log from Intel

Created attachment 144488 [details]
xend-debug log from Intel

Are you doing anything "strange" with xauthority?  Are there any SELinux avcs?

Intel is still seeing the same problems with a fresh Snapshot 7 installation.

OK.  I can finally reproduce this, although I get a slightly different error
message from what was in this ticket before.  Here's the setup I have:

1.  RHEL-5 i386 dom0, SELinux enabled, fresh reboot.
2.  Start X, and log into the console.  This is critical, I don't get the same
problem when doing this via ssh.
3.  Install RHEL-5 as a fully virt guest, using: virt-install -n rhel5fvtest -r
500 -f /var/lib/xen/images/rhel5fvtest.dsk -s 6 --nonsparse --vnc -v -c
/var/lib/xen/images/boot.iso (boot.iso copied over from a RC tree)
4.  Do the install, accepting all defaults
5.  After the install, reboot, and then shut down the guest
6.  Edit the config file, comment out "vnc=1" and "vncunused=1", and add "sdl=1".
7.  Try to start the guest

In my case, I get the following in my qemu-dm log:

Xlib: connection to "localhost:0.0" refused by server
Xlib: No protocol specified

Xlib: connection to "localhost:0.0" refused by server
Xlib: No protocol specified

Could not initialize SDL - exiting

I also did a wireshark capture, and what I see is a pretty standard X11 Initial
Connection Request, but then the Initial Connection Reply has success=0, with a
reason of "No protocol specified."

I seem to be able to use one of three ways to get out of this:
1.  Turn off SELinux (i.e. setenforce 0).  Doing this will allow the SDL domain
to start, but as soon as you turn SELinux back on the domain will start failing
again.
2.  Run "xhost +" for the X server.  This will also allow the SDL domain to
start, but doing "xhost -" again causes it to start failing.
3.  Restart xend "xend start ; xend stop", as mentioned earlier in this ticket.
 This will allow the SDL domain to start, and will continue to allow SDL domains
to start, up until you restart the machine.

If anyone needs additional information, or a box to reproduce, let me know since
I now know how to do it.

Chris Lalancette

Can you attach your latest  xend.log file corresponding to comment #27 - i want
to see the config XenD is getting when you created it via the console.

Created attachment 149394 [details]
Xend.log corresponding to comment #27 failure

I also just noticed that I am getting this on the terminal I started X (startx)
from:

AUDIT: Tue Mar  6 17:38:07 2007: 3484 X: client 16 rejected from IP 127.0.0.1
AUDIT: Tue Mar  6 17:38:07 2007: 3484 X: client 16 rejected from IP 127.0.0.1

I get two of those every time I try, and fail, to start an SDL domain.

Chris Lalancette

The more I think about this, the more it seems to me an SELinux problem with
xend reading /root/.Xauthority (although I don't get any audit messages in
/var/log/audit):

1.  In the case of "xhost +", .Xauthority is completely ignored; so while xend
might fail to read .Xauthority, it doesn't actually matter since no
authentication is being used.
2.  In the case of SELinux being disabled, it obviously allows /root/.Xauthority
to be read.
3.  In the case of xend stop; xend start, it actually gets the context of the
user who ran it.  So, for instance, after a fresh boot, "ps -efwZ | grep xend"
looks like:

[root@lore ~]# ps -efwZ | grep xend
system_u:system_r:xend_t        root      2877     1  0 17:37 ?        00:00:00
python /usr/sbin/xend start
system_u:system_r:xend_t        root      2882  2877  0 17:37 ?        00:00:00
python /usr/sbin/xend start
system_u:system_r:xend_t        root      2883     1  0 17:37 ?        00:00:00
blktapctrl
root:system_r:unconfined_t:SystemLow-SystemHigh root 5363 5208  0 20:36 pts/2
00:00:00 grep xend

But after a xend stop; xend start, the same command looks like:

[root@lore ~]# ps -efwZ | grep xend
system_u:system_r:xend_t        root      2883     1  0 17:37 ?        00:00:00
blktapctrl
root:system_r:unconfined_t:SystemLow-SystemHigh root 5378 1  0 20:36 ? 00:00:00
python /usr/sbin/xend start
root:system_r:unconfined_t:SystemLow-SystemHigh root 5379 5378  0 20:36 ?
00:00:00 python /usr/sbin/xend start
root:system_r:unconfined_t:SystemLow-SystemHigh root 5400 5208  0 20:36 pts/2
00:00:00 grep xend

So it looks like xend got restarted as "unconfined_t", which now allows it to
read /root/.Xauthority, and it happily will do so until the next reboot (or
possibly, service xend restart), when xend gets reverted to xend_t.

Chris Lalancette

Eureka!  Changing the context of /root to system_u:object_r:xen_image_t (from
root:object_r:user_home_dir_t), and changing the context of /root/.Xauthority to
the same, allows an SDL guest to start properly.  I'm sure this is the wrong
solution, but I just wanted to prove that this would do it.

Chris Lalancette

Dan,
     I'm adding you to the CC list since I think this is an SELinux context
problem, despite the lack of relevant AVC's in /var/log/audit/audit.log.  To
summarize the situation (more details are in previous comments):

1.  Starting a Xen guest, at an X console (not via ssh), using SDL fails to
start with "Could not initialize SDL".
2.  Restarting xend by hand (i.e. # xend stop; xend start) "fixes" the problem
by changing the context of the xend process to unconfined_t.  Also, changing the
context of /root and /root/.Xauthority to system_u:object_r:xen_image_t also
fixes the problem.

It feels like xend needs to be able to read /root/.Xauthority in order to
successfully start up the new X window, but it is being prevented from doing so
by SELinux.  Please take a look and let me know if you have recommendations.

Thanks,
Chris Lalancette

XenD really has no business being given access to per-user home directory files
like Xauthority. Looking at the source it appears possible to give Xen the path
to an alternate Xauthority file with the 'xauthority' config parameter. This
would let you re-point it at a file under /etc/xen, or /var/lib/xen where the
SELinux policy already allows writes.

IMHO, this is just another example illustrating the fundemental brokenness of
the whole SDL display idea though. You have to set Xauthority / display info at
guest startup, but you can't ever change it after that. A guest will likely
outlive the lifetime of your X session. In addition killing the X session will
kill the entire guest VM's device model. Add on top the SELinux security issues
in this ticket, and SDL becomes totally unsupportable.

Dan,
     I don't necessarily disagree with your points.  However, I have been told
the policy is generally "if we ship it, we support it".  I'd like to see if the
SELinux people have any comment, or some tricky way out of this.  If not, we can
just release note it for now.

Chris Lalancette

You can generate policy to allow the xend process to read the /root directory
with grep xen /var/log/audit/audit.log | audit2allow -M myxend  

Then load the generated pp file. 

We could add a boolean to selinux policy to allow xen to read /root directories,
but I agree with Daniel that this seems a little broken.

Dan,
     Two things:

1.  There don't seem to be any relevant AVC's in /var/log/audit/audit.log; I'll
upload audit.log, if you'd like to look at them yourself.

2.  I still agree that letting xend tromp willy-nilly through the filesystem
seems bad, and is not something the policy should generally allow.  It's just
that this is shipped broken; it would be much better for customers, and for
support, if this actually worked.  Is it possible to set the default policy so
that xend could read only /root/.Xauthority, and nothing else?  I don't think
that would open up much of a security hole, and would be much better for
customers (and support) if this worked out-of-the-box, so to speak.

Chris Lalancette

Created attachment 149687 [details]
Audit log when failing to start SDL domain

This is a fresh audit log from a failing SDL domain.  I did the equivalent of
the following:

rm -f /var/log/audit/audit.log ; reboot ; startx ; xm create rhel5fvtest

And then uploaded that resulting audit.log here.

The reporter of the initial bug said that he couldn't reproduce on 5.1.  I don't
think we did anything in particular to fix it, though.  Closing out as
CURRENTRELEASE.

Chris Lalancette

Clearing out old flags for reporting purposes.

Chris Lalancette