Hide Forgot
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:
Does chcon -t xm_exec_t /usr/sbin/xl Solve your problem?
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.
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.
Running xl out of an init script will now transition to virsh_t.