Bug 699398

Summary:	SELinux targeted policy restricts xm but not xl
Product:	[Fedora] Fedora	Reporter:	W. Michael Petullo <mike>
Component:	selinux-policy-targeted	Assignee:	Miroslav Grepl <mgrepl>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ben Levenson <benl>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	dwalsh
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-10-07 14:10:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description W. Michael Petullo 2011-04-25 14:27:40 UTC

Description of problem:
New versions of the Xen (e.g., xen-4.1.0-0.1.rc8.fc15.x86_64) provide a new utility to load domains called "xl." Xl operates in a similar manner to xm. I've heard that xl will eventually replace xm.

Version-Release number of selected component (if applicable):
xen-4.1.0-0.1.rc8.fc15.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Place an OS kernel in /some/path (not /var/lib/xen/images/)
2. Try to load it with xm.
3. Try to load it with xl.
  
Actual results:
Step 2 fails as expected because the kernel does not have the proper label (The system labels domain configurations in /var/lib/xen/images/ as unconfined_u:object_r:xen_image_t:s0)

Expected results:
But, step three succeeds even though the kernel's label is system_u:object_r:default_t:s0. 

Additional info:

Comment 1 Daniel Walsh 2011-04-25 14:51:07 UTC

Does chcon -t xm_exec_t /usr/sbin/xl

Solve your problem?

Comment 2 W. Michael Petullo 2011-04-25 20:43:07 UTC

I tried to set the context of /usr/sbin/xl to:

virsh_exec_t (same label as xm)
xend_exec_t
xm_exec_t

In all three cases, xl continued to load a kernel labeled as "system_u:object_r:default_t:s0."

I'm not yet familiar with the Xen portion of the SELinux policy, but I took a quick look at xl using strace. The program is not exec'ing anything that could be run as a different context. Xl doesn't link against the SELinux libraries either. It just opens the kernel image itself and this succeeds.

Comment 3 Daniel Walsh 2011-04-25 20:48:33 UTC

We are not actually trying to block the execution of virsh, xm and now xl, this labeling is more for other domains to use.

running any of these apps from unconfined_t will stay unconfined.

Comment 4 Daniel Walsh 2011-04-25 20:50:02 UTC

Running xl out of an init script will now transition to virsh_t.