Bug 735442
| Summary: | Sanlock socket is incorrectly labelled for SELinux | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Daniel Berrangé <berrange> |
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | ajia, dyuan, mzhan, rwu, veillard, weizhan |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-0.9.4-8.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-12-06 11:28:02 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
It has still a little weird, I can't also reproduce this issue on 0.9.4-1.el6, the following is my steps, maybe I'm missing some important stuff, please correct me if wrong: # grep "lock_manager" /etc/libvirt/qemu.conf lock_manager = "sanlock" # service libvirtd restart Stopping libvirtd daemon: [ OK ] Starting libvirtd daemon: [ OK ] # virsh start vr-rhel5u4-x86_64-kvm error: Failed to start domain vr-rhel5u4-x86_64-kvm error: internal error unsupported configuration: Read/write, exclusive access, disks were present, but no leases specified # grep -i avc /var/log/audit/audit.log Notes: without any "avc: denied" error. BTW, whether I need to start sanlock daemon? I try turn on/off it, the rest result is the same to previous, I will research it again. Alex I met the following AVC denied error when I try the above steps on libvirt-0.9.4-1.el6.x86_64 and libvirt-lock-sanlock-0.9.4-1.el6.x86_64:
# grep -i avc /var/log/audit/audit.log
type=AVC msg=audit(1315593958.191:44869): avc: denied { write } for pid=21797 comm="qemu-kvm" path="/var/lib/libvirt/images/rhel6.img" dev=sda12 ino=525859 scontext=system_u:system_r:svirt_t:s0:c338,c512 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
type=AVC msg=audit(1315593958.191:44870): avc: denied { write } for pid=21797 comm="qemu-kvm" path="/var/lib/libvirt/images/rhel6.img" dev=sda12 ino=525859 scontext=system_u:system_r:svirt_t:s0:c338,c512 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
type=AVC msg=audit(1315593963.818:44871): avc: denied { write } for pid=21797 comm="qemu-kvm" path="/var/lib/libvirt/images/rhel6.img" dev=sda12 ino=525859 scontext=system_u:system_r:svirt_t:s0:c338,c512 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
type=AVC msg=audit(1315593963.818:44872): avc: denied { write } for pid=21797 comm="qemu-kvm" path="/var/lib/libvirt/images/rhel6.img" dev=sda12 ino=525859 scontext=system_u:system_r:svirt_t:s0:c338,c512 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
type=AVC msg=audit(1315593963.820:44873): avc: denied { write } for pid=21797 comm="qemu-kvm" path="/var/lib/libvirt/images/rhel6.img" dev=sda12 ino=525859 scontext=system_u:system_r:svirt_t:s0:c338,c512 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
Alex->Daniel, I'm not sure whether these AVC denied are the same to you?
I haven't found any AVC denied on libvirt-0.9.4-11.el6.x86_64, so it's okay for me.
Daniel, if it's fine for you, I will move the bug to VERIFIED status.
Thanks,
Alex
> # virsh start vr-rhel5u4-x86_64-kvm
> error: Failed to start domain vr-rhel5u4-x86_64-kvm
> error: internal error unsupported configuration: Read/write, exclusive access,
> disks were present, but no leases specified
There are two modes of dealing with sanlock, either you can manually add <lease> elements to the XML, or you can ask libvirt todo it automatically. This error messages shows that you do not have any <lease> elements, and automatic creation isn't enabled.
To fix this edit /etc/libvirt/qemu-sanlock.conf and enable
'auto_disk_leases = 1'
and make sure sanlock is running, and then restart libvirtd.
(In reply to comment #5) Hi Daniel, Thanks for your comment, but I can't still reproduce this issue, the following is my steps: # lsmod | grep softdog softdog 3993 2 # service wdmd start Starting wdmd: [ OK ] # service wdmd status wdmd (pid 18610) is running... # service sanlock start Starting sanlock: [ OK ] # service sanlock status sanlock (pid 18649) is running... # grep "^auto_disk_leases" /etc/libvirt/qemu-sanlock.conf auto_disk_leases = 1 Notes, if enable lock_manager = "sanlock" in qemu.conf then restart libvirtd service, libvirtd will dead, this is known bug, so I haven't edited qemu.conf followed by the step. # service libvirtd restart Stopping libvirtd daemon: [ OK ] Starting libvirtd daemon: [ OK ] # virsh start vr-rhel5u4-x86_64-kvm Domain vr-rhel5u4-x86_64-kvm started Notes, guest can be successfully stared. # grep -i avc /var/log/audit/audit.log Notes, without any "avc: denied" error. Version-Release number of selected component: # uname -r 2.6.32-193.el6.x86_64 # rpm -q libvirt libvirt-0.9.4-1.el6.x86_64 # rpm -q libvirt-lock-sanlock libvirt-lock-sanlock-0.9.4-1.el6.x86_64 Alex Here is a better set of steps to reproduce with 0.9.4-7.el6
$ service libvirtd stop
$ yum install /usr/bin/augtool
$ augtool
augtool> set /files/etc/libvirt/qemu.conf/lock_manager "sanlock"
augtool> set /files/etc/libvirt/qemu-sanlock.conf/host_id 1
augtool> set /files/etc/libvirt/qemu-sanlock.conf/auto_disk_leases 1
augtool> set /files/etc/libvirt/qemu-sanlock.conf/disk_lease_dir "/var/lib/libvirt/sanlock"
augtool> save
Saved 1 file(s)
augtool> quit
$ echo 'SANLOCKOPTS="-w 0"' > /etc/sysconfig/sanlock
$ /etc/init.d/sanlock start
Starting sanlock: [ OK ]
$ ps -axuwf | grep sanlock
root 3953 2.0 5.8 325232 46748 ? SLsl 12:13 0:00 sanlock daemon -w 0
$ service libvirtd start
Starting libvirtd daemon: [ OK ]
$ ps -axuwf | grep libvirtd
root 4093 10.5 0.8 387332 6816 ? Sl 12:14 0:00 libvirtd --daemon
$ qemu-img create /var/lib/libvirt/images/disk.img 100M
Formatting '/var/lib/libvirt/images/disk.img', fmt=raw size=104857600
$ cat > /root/demo1.xml <<EOF
<domain type='qemu'>
<name>demo1</name>
<memory>219200</memory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64'>hvm</type>
<boot dev='cdrom'/>
</os>
<devices>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/disk.img'/>
<target dev='vda' bus='virtio'/>
</disk>
<input type='mouse' bus='ps2'/>
<graphics type='spice' autoport='yes' listen='0.0.0.0'/>
</devices>
</domain>
EOF
$ virsh create demo1.xml
Domain demo1 created from demo1.xml
$ grep AVC /var/log/audit/audit.log
type=AVC msg=audit(1315912779.785:86598): avc: denied { read write } for pid=4276 comm="qemu-system-x86" path="socket:[2221414]" dev=sockfs ino=2221414 scontext=system_u:system_r:svirt_t:s0:c304,c446 tcontext=unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=unix_stream_socket
I can reproduce this issue on 6.2 Beta with libvirt-0.9.4-1.el6.x86_64 based on the above steps, however, there are some informations are different from above:
# virsh create demo1.xml
error: Failed to create domain from demo1.xml
error: internal error unable to set security context 'system_u:system_r:svirt_t:s0:c268,c763' on fd 3: Operation not permitted
Notes: can't successfully create a guest in here.
# grep AVC /var/log/audit/audit.log
type=AVC msg=audit(1315968980.836:47372): avc: denied { sigkill } for pid=28772 comm="sanlock" scontext=unconfined_u:system_r:sanlock_t:s0 tcontext=unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1315969130.054:47390): avc: denied { kill } for pid=28772 comm="sanlock" capability=5 scontext=unconfined_u:system_r:sanlock_t:s0 tcontext=unconfined_u:system_r:sanlock_t:s0 tclass=capability
Notes: sometimes, I can see another AVC denied except for first one.
The selinux issue still exists for libvirt-0.9.4-11.el6.x86_64, which isn't fine for me:
1. # service libvirtd restart
Raw Audit Messages
type=AVC msg=audit(1315969550.576:47483): avc: denied { kill } for pid=28772 comm="sanlock" capability=5 scontext=unconfined_u:system_r:sanlock_t:s0 tcontext=unconfined_u:system_r:sanlock_t:s0 tclass=capability
2. # virsh create demo1.xml
error: Failed to create domain from demo1.xml
error: internal error Failed to open socket to sanlock daemon: Operation not permitted
Raw Audit Messages
type=AVC msg=audit(1315970963.788:47623): avc: denied { connectto } for pid=30081 comm="libvirtd" path="/var/run/sanlock/sanlock.sock" scontext=system_u:system_r:svirt_t:s0:c525,c976 tcontext=unconfined_u:system_r:sanlock_t:s0 tclass=unix_stream_socket
Daniel, please confirm this on libvirt-0.9.4-11.el6.x86_64.
Alex
These two audit messages you see:
type=AVC msg=audit(1315969550.576:47483): avc: denied { kill } for pid=28772
comm="sanlock" capability=5 scontext=unconfined_u:system_r:sanlock_t:s0
tcontext=unconfined_u:system_r:sanlock_t:s0 tclass=capability
type=AVC msg=audit(1315970963.788:47623): avc: denied { connectto } for
pid=30081 comm="libvirtd" path="/var/run/sanlock/sanlock.sock"
scontext=system_u:system_r:svirt_t:s0:c525,c976
tcontext=unconfined_u:system_r:sanlock_t:s0 tclass=unix_stream_socket
are both SELinux policy bugs - can you file a new BZ for those against selinux-policy.
(In reply to comment #9) > These two audit messages you see: > > type=AVC msg=audit(1315969550.576:47483): avc: denied { kill } for pid=28772 > comm="sanlock" capability=5 scontext=unconfined_u:system_r:sanlock_t:s0 > tcontext=unconfined_u:system_r:sanlock_t:s0 tclass=capability Sometimes, I can't reproduce this issue, so haven't filed a new bug about it. > > > type=AVC msg=audit(1315970963.788:47623): avc: denied { connectto } for > pid=30081 comm="libvirtd" path="/var/run/sanlock/sanlock.sock" > scontext=system_u:system_r:svirt_t:s0:c525,c976 > tcontext=unconfined_u:system_r:sanlock_t:s0 tclass=unix_stream_socket > > https://bugzilla.redhat.com/show_bug.cgi?id=738188 Daniel, because I haven't seen "avc: denied" from Comment 7 on libvirt-0.9.4-11.el6.x86_64 again, so whether I can move the bug to VERIFIED status? Thanks, Alex There is a question in here, in fact, I met AVC issue was different from you on libvirt-0.9.4-1.el6.x86_64:
$ grep AVC /var/log/audit/audit.log
type=AVC msg=audit(1315912779.785:86598): avc: denied { read write } for
pid=4276 comm="qemu-system-x86" path="socket:[2221414]" dev=sockfs ino=2221414
scontext=system_u:system_r:svirt_t:s0:c304,c446
tcontext=unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=unix_stream_socket
The above 'comm' is 'qemu-system-x86', I have never seen this, and my 'comm' is 'sanlock' (see comment 8), Daniel, maybe I need to retry it on 0.9.4-7.el6? however, IMHO, it should be same result if 0.9.4-7.el6 hasn't fixed these codes.
Except this, others are okay for me on libvirt-0.9.4-11.el6.x86_64, and the another 2 selinux issues are selinux-policy bugs not libvirt.
Thanks,
Alex
I retried this on rhel6.2 beta with libvirt-0.9.4-12.el6.x86_64, I haven't found AVC denied like Comment 7, so move the bug to VERIFIED status. BTW, selinux-policy is 3.7.19-112.el6 version. 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/RHBA-2011-1513.html |
Description of problem: When libvirt is running with sanlock, we intentionally leak the UNIX domain socket to QEMU. Unfortunately the current code incorrectly labels the socket resulting in an SELinux AVC when starting a guest with sanlock in use. Version-Release number of selected component (if applicable): 0.9.4-1.el6 How reproducible: Only if starting a guest with sanlock enabled Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Upstream fix: commit 64bdec384101f7a5e6989ee871b360c110ade571 Author: Daniel P. Berrange <berrange> Date: Fri Aug 26 16:06:31 2011 +0100 Fix sanlock socket security labelling It is not possible to change the label of a TCP socket once it has been opened. When creating a TCP socket care must be taken to ensure the socket creation label is set & then cleared. Remove the bogus call to virSecurityManagerSetProcessFDLabel from the lock driver guest setup code and instead make use of virSecurityManagerSetSocketLabel