RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 823857 - guest can't start with unable to set security context error if guests are unconfined
Summary: guest can't start with unable to set security context error if guests are unc...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.3
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 853043
TreeView+ depends on / blocked
 
Reported: 2012-05-22 10:21 UTC by yanbing du
Modified: 2013-02-21 07:15 UTC (History)
7 users (show)

Fixed In Version: libvirt-0.10.0-0rc0.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 853043 (view as bug list)
Environment:
Last Closed: 2013-02-21 07:15:18 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
guest XML file (1.89 KB, text/plain)
2012-07-23 03:50 UTC, yanbing du 		no flags Details
libvirtd debug log (830.21 KB, text/plain)
2012-07-24 06:45 UTC, yanbing du 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0276 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2013-02-20 21:18:26 UTC

Description yanbing du 2012-05-22 10:21:55 UTC 
Description of problem:
If set security_default_confined=0 in qemu.conf, that means all then guests will be unconfined by default, then guests can not start with error like:
error: unable to set security context 'system_u:object_r:svirt_image_t' on XX
If set selinux to permissive, then guest can start, and has seclabel with type=none.

Version-Release number of selected component (if applicable):
kernel-2.6.32-270.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.293.el6.x86_64
libvirt-0.9.10-20.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Make sure selinux is Enforcing

2. Before set security_default_confined, prepare a guest, and start it, then check the guest's seclabel

#  virsh dumpxml rhel62|grep seclabel -A 3
  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <label>system_u:system_r:svirt_t:s0:c560,c742</label>
    <imagelabel>system_u:object_r:svirt_image_t:s0:c560,c742</imagelabel>
  </seclabel>
</domain>

3. Set security_default_confined=0 in qemu.conf and restart libvirtd
4. Recheck the guest's seclabel
#  virsh dumpxml rhel62|grep seclabel -A 3
  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <label>system_u:system_r:svirt_t:s0:c560,c742</label>
    <imagelabel>system_u:object_r:svirt_image_t:s0:c560,c742</imagelabel>
  </seclabel>
</domain>
5. Destroy the guest, and restart it
# virsh start rhel62
error: Failed to start domain rhel62
error: unable to set security context 'system_u:object_r:svirt_image_t' on '/var/lib/libvirt/images/rhel62.qcow2': Invalid argument
6. 
# ll -Z /var/lib/libvirt/images/rhel62.qcow2 
-rw-r--r--. root root system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/rhel62.qcow2

  
Actual results:
As step 5 shows, guest can't start with nable to set security context error

Expected results:
guest can start and has a seclabel label:
 <seclabel type='none'/>

Additional info:
#tail -f /var/log/libvirt/libvirtd.log 
<snip>
012-05-22 10:03:21.808+0000: 9457: error : SELinuxSetFileconHelper:449 : unable to set security context 'system_u:object_r:svirt_image_t' on '/var/lib/libvirt/images/test.raw': Invalid argument
</snip>

BTW, 
# setenforce 0

# virsh start rhel62
Domain rhel62 started

# virsh dumpxml rhel62|grep seclabel 
  <seclabel type='none'/>
Comment 4 Jiri Denemark 2012-07-19 13:20:19 UTC 
Hmm, I wasn't able to reproduce this issue, everything works as expected. What is the output of virsh dumpxml --inactive rhel62 | grep seclabel -A 3 ?
Comment 5 yanbing du 2012-07-23 03:49:34 UTC 
(In reply to comment #4)
> Hmm, I wasn't able to reproduce this issue, everything works as expected.
> What is the output of virsh dumpxml --inactive rhel62 | grep seclabel -A 3 ?
Hi, Jiri
I can always reproduce this bug. And after destroy the guest, the output of command virsh dumpxml --inactive rhel62 | grep seclabel -A 3 is empty. 
The packages i uesd are:
kernel-2.6.32-279.2.1.el6.x86_64
libvirt-0.9.10-21.el6_3.3.x86_64
qemu-kvm-rhev-0.12.1.2-2.295.el6.x86_64
Comment 6 yanbing du 2012-07-23 03:50:55 UTC 
Created attachment 599675 [details]
guest XML file
Comment 7 Jiri Denemark 2012-07-23 12:09:51 UTC 
Hmm, that's interesting. Could you catch debug logs from libvirtd while trying to start a domain with security_default_confined=0?
Comment 8 yanbing du 2012-07-24 06:45:48 UTC 
Created attachment 599925 [details]
libvirtd debug log

config libvirtd.conf with:
log_level = 1
log_outputs="1:file:/tmp/libvirtd.log"
Comment 9 Jiri Denemark 2012-07-24 12:28:49 UTC 
Oops, I didn't have any disks configured in my domain, which means there was nothing to relable in the first place. I can reproduce the issue now.
Comment 10 Jiri Denemark 2012-07-25 09:52:19 UTC 
Actually, the seclabel is correctly set to "none", you just need to swap steps 4 and 5 sinc seclabel of running domains doesn't change. However, even if domain seclabel is "none", we still try to generate and use image label for disks. This issue should be fixed by
https://www.redhat.com/archives/libvir-list/2012-July/msg01385.html
Comment 11 Jiri Denemark 2012-07-27 17:04:55 UTC 
The patch from comment 10 was wrong. Anyway, this is now fixed upstream by v0.9.13-207-gce53382:

commit ce53382ba28179d3a504b29b4f888b6e130d53f0
Author: Jiri Denemark <jdenemar>
Date:   Wed Jul 25 14:38:27 2012 +0200

    security: Skip labeling resources when seclabel defaults to none
    
    If a domain is explicitly configured with <seclabel type="none"/> we
    correctly ensure that no labeling will be done by setting
    norelabel=true. However, if no seclabel element is present in domain XML
    and hypervisor is configured not to confine domains by default, we only
    set type to "none" without turning off relabeling. Thus if such a domain
    is being started, security driver wants to relabel resources with
    default label, which doesn't make any sense.
    
    Moreover, with SELinux security driver, the generated image label lacks
    "s0" sensitivity, which causes setfilecon() fail with EINVAL in
    enforcing mode.
Comment 13 Wayne Sun 2012-08-03 05:33:16 UTC 
pkgs:
# rpm -q libvirt qemu-kvm-rhev kernel
libvirt-0.10.0-0rc0.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.297.el6_3.x86_64
kernel-2.6.32-291.el6.x86_64

steps:
Following exact steps in description, 
step 5:
# virsh start aaa
Domain aaa started

# virsh dumpxml aaa|grep seclabel -A 3
  <seclabel type='none'/>
</domain>

# ll -Z /var/lib/libvirt/images/rhel6u2.qcow2 
-rw-r--r--. qemu qemu system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/rhel6u2.qcow2

This is working now.
Comment 14 errata-xmlrpc 2013-02-21 07:15:18 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html
Note You need to log in before you can comment on or make changes to this bug.