Bug 1105939

Summary:	Fail to start guest while disable the default security labeling
Product:	Red Hat Enterprise Linux 7	Reporter:	zhenfeng wang <zhwang>
Component:	libvirt	Assignee:	Ján Tomko <jtomko>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	ajia, dyuan, gsun, jtomko, lhuang, mzhan, rbalakri, ydu
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	All
Whiteboard:
Fixed In Version:	libvirt-1.2.7-1.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1105954 (view as bug list)		Environment:
Last Closed:	2015-03-05 07:37:29 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:
Embargoed:
Bug Depends On:
Bug Blocks:	1105954

Description zhenfeng wang 2014-06-09 02:07:42 UTC

Description of problem:
Fail to start guest while set security_default_confined = 0 in qemu.conf
and add <seclabel type='none' model='dac'/> in guest's xml

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-1.5.3-60.el7ev_0.2.x86_64
libvirt-1.1.1-29.el7.x86_64
kernel-3.10.0-123.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Disable the default security labeling in /etc/libvirt/qemu.conf
 security_default_confined = 0
 #service libvirtd restart

2.Start a normal guest
#virsh start rhel7

3.After the guest start, check the guest's xml we could see the following content
was added automatically.
#virsh dumpxml rhel7
--
  <seclabel type='none' model='selinux'/>
--
4.Destroy the guest, then add the following content to the guest's xml
# virsh dumpxml rhel7 |grep dac
  <seclabel type='none' model='dac'/>

5.Start the guest, the guest will fail to start with unknow error
# virsh start rhel7
error: Failed to start domain rhel7
error: An error occurred, but the cause is unknown

6.Re-try the upper steps with rhel6.6, also fail to start the guest, however
got a different error, also got some info from the libvirt and qemu's log

# virsh start rhel7k
error: Failed to start domain rhel7k
error: internal error Unknown failure during hook execution

check the libvirtd log
2014-06-04 07:09:53.842+0000: 11599: error : virCommandHandshakeWait:2460 : internal error Unknown failure during hook execution

check the qemu log
2014-06-04 07:09:53.792+0000: starting up
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name rhel7k -S -M rhel6.4.0 -enable-kvm -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 995a1b49-0924-ea37-107b-d9531cb6f59a -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel7k.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/rhel7.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=22,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:38:0c:9f,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/rhel7k.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/rhel7k.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel2,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel2,id=channel2,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
libvirt:  error : An error occurred, but the cause is unknown
2014-06-04 07:09:53.843+0000: shutting down

Actual results:
Fail to start guest with unknown failure

Expected results:
If we allow start guest in this scenario, the guest should be start successfully, if not, it should give clear error

Comment 2 Ján Tomko 2014-06-10 08:22:05 UTC

Fixed upstream by:
commit f9bf63e673c11cd189748c29b6ea7d2cf19c8da7
Author:     Ján Tomko <jtomko>
AuthorDate: 2014-06-09 16:23:52 +0200
Commit:     Ján Tomko <jtomko>
CommitDate: 2014-06-10 10:18:24 +0200

    SELinux: don't fail silently when no label is present
    
    This fixes startup of a domain with:
    <seclabel type='none' model='dac'/>
    on a host with selinux and dac drivers and
    security_default_confined = 0
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1105939
    https://bugzilla.redhat.com/show_bug.cgi?id=1102611

git describe: v1.2.5-81-gf9bf63e

Comment 4 zhengqin 2014-08-21 08:13:33 UTC

I could reproduce it with libvirt-1.1.1-29.el7.x86_64 as following steps:


1.Disable the default security labeling in /etc/libvirt/qemu.conf
 security_default_confined = 0
 #service libvirtd restart

2.Start a normal guest
#virsh start rhel6

3.After the guest start, check the guest's xml we could see the following content
was added automatically.
#virsh dumpxml rhel6
--
  <seclabel type='none' model='selinux'/>
--
4.Destroy the guest, then add the following content to the guest's xml
# virsh dumpxml rhel6 |grep dac
  <seclabel type='none' model='dac'/>

5.Start the guest, the guest will fail to start with unknow error
# virsh start rhel6
error: Failed to start domain rhel6
error: An error occurred, but the cause is unknown

Comment 5 zhengqin 2014-08-21 10:24:24 UTC

Verified this with libvirt-1.2.7-1.el7.x86_64:

1.Disable the default security labeling in /etc/libvirt/qemu.conf
 security_default_confined = 0
 #service libvirtd restart

2.Start a normal guest
#virsh start rhel6

3.After the guest start, check the guest's xml we could see the following content
was added automatically.
#virsh dumpxml rhel6
--
  <seclabel type='none' model='selinux'/>
--
4.Destroy the guest, then add the following content to the guest's xml
# virsh dumpxml rhel6 |grep dac
  <seclabel type='none' model='dac'/>

5.Start the guest, the guest could start successfully:
# virsh start rhel6
Domain rhel6 started

Comment 6 Luyao Huang 2014-09-04 04:58:50 UTC

hi Jan Tomko,

I have found a issue with libvirt-1.2.8-1:

1.Disable the default security labeling in /etc/libvirt/qemu.conf
 security_default_confined = 0
 #service libvirtd restart

2.start two guest without config security label
# virsh start r6
Domain r6 started

# virsh start win7
Domain win7 started

# virsh dumpxml r6

  <seclabel type='none' model='selinux'/>

# virsh dumpxml win7

 <seclabel type='none' model='selinux'/>

3.# virsh list --all
 Id    Name                           State
----------------------------------------------------
 2     r6                             running
 3     win7                           running

3.restart libvirtd
 #service libvirtd restart
4.# virsh list --all
 Id    Name                           State
----------------------------------------------------
 5     win7                           running
 -     r6                             shut off

5.# ps aux|grep r6
root     19008  0.0  0.0 112640   964 pts/0    S+   12:51   0:00 grep --color=auto r6

Is this issue is the same issue with this bug and will fix in this bug?
Or a new bug?

Thanks,
Luyao Huang

Comment 7 Luyao Huang 2014-09-04 06:33:18 UTC

Log from /var/log/libvirt/libvirtd.log:


2014-09-04 06:31:02.161+0000: 8826: info : libvirt version: 1.2.8, package: 1.el7 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2014-09-02-05:19:38, x86-021.build.eng.bos.redhat.com)
2014-09-04 06:31:02.161+0000: 8826: error : qemuAgentIO:634 : internal error: End of file from monitor
2014-09-04 06:31:02.192+0000: 8881: error : virSecuritySELinuxReserveSecurityLabel:758 : internal error: MCS level for existing domain label  already reserved

Comment 8 Ján Tomko 2014-09-04 10:49:38 UTC

(In reply to Luyao Huang from comment #6)
Hi, that's a new bug.

Comment 9 Luyao Huang 2014-09-05 01:12:23 UTC

(In reply to Jan Tomko from comment #8)
> (In reply to Luyao Huang from comment #6)
> Hi, that's a new bug.

Thanks,and filed a new bug 1138487 in RHEL7 and clone a bug 1138488 in RHEL6

Comment 10 zhenfeng wang 2014-11-25 08:47:49 UTC

Verify the bug with libvirt-1.2.8-8.el7.x86_64
steps
1.Disable the default security labeling in /etc/libvirt/qemu.conf
 security_default_confined = 0
 #service libvirtd restart

2.Start a normal guest
#virsh start rhel7

3.After the guest start, check the guest's xml we could see the following content
was added automatically.
#virsh dumpxml rhel7
--
  <seclabel type='none' model='selinux'/>
--
4.Destroy the guest, then add the following content to the guest's xml
# virsh dumpxml rhel7 |grep dac
  <seclabel type='none' model='dac'/>

5.Start the guest, the guest will fail to start since libvirt won't change the uid and gid of the vm and vm image with type='none' model='dac' seclabel configured, this is the expect result, more explanation, you can refer the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=1108593#c7

# virsh start rhel7.0
error: Failed to start domain rhel7.0
error: internal error: process exited while connecting to monitor: 2014-11-25T08:37:13.827751Z qemu-kvm: -drive file=/var/lib/libvirt/images/rhel7.0.qcow2,if=none,id=drive-virtio-disk0,format=qcow2: could not open disk image /var/lib/libvirt/images/rhel7.0.qcow2: Could not open '/var/lib/libvirt/images/rhel7.0.qcow2': Permission denied

6.Retest the steps in comment6 with the latest libvirt packet, all steps could get the expect result, so mark this bug verifed

Comment 12 errata-xmlrpc 2015-03-05 07:37:29 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.

https://rhn.redhat.com/errata/RHSA-2015-0323.html