Bug 505016
| Summary: | selinux policy prevents (svirt_t) "read" random_device_t | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexander Kahl <fedora> | |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | low | |||
| Version: | 11 | CC: | dwalsh, dwmw2, gcosta, itamar, jaswinder, klaus, markmc, mgrepl, mkearey, virt-maint | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | 3.6.12-93.fc11 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 552763 (view as bug list) | Environment: | ||
| Last Closed: | 2010-01-19 19:34:38 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: | ||||
I guess the question is can we get all of the qemu's to use /dev/urandom and not have SELinux policy loosened. Or we can add the ability to read /dev/random. Reading /dev/random is considered more dangerous then reading /dev/urandom from a security point of view I have been told. You can add these rules for now using # grep avc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Hi Daniel, thanks for the advice, this helps for now. Should I file another bug against qemu or report upstream instead? No this is now a qemu bug, unless they argue that qemu needs /dev/random. Dan, I have looked at this bug. qemu uses gnutls for TLS secured vnc sessions. gnutls depends on libgcrypt. And libgcrypt uses a concept of rnd 'modules' for managing the random source. The gcrypt guide explains it: http://www.gnupg.org/documentation/manuals/gcrypt/Random_002dNumber-Subsystem-Architecture.html Essentially, IF we have no other sources of entropy, we must default to 'rndlinux' on Linux. rndlinux by design requires access to both /dev/random and /dev/urandom. Anything that uses gnutls we need to allow access to both /dev/random and /dev/urandom in SElinux policy, or setup an alternative random source that gcrypt can use as an alternative. Cheers Miroslav, add dev_read_rand(virtd_domain) dev_read_urand(virtd_domain) To F-12 and F-11 I don't think it is worth it to make this a boolean. Fixed in selinux-policy-3.6.12-93.fc11.noarch selinux-policy-3.6.32-67.fc12.noarch selinux-policy-3.6.12-93.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/selinux-policy-3.6.12-93.fc11 selinux-policy-3.6.12-93.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0446 selinux-policy-3.6.12-93.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. Looks like this also affects RHEL5.4
type=AVC msg=audit(1266004735.924:260): avc: denied { read } for pid=9115 comm="qemu-kvm" name="random" dev=tmpfs ino=2394 scontext=root:system_r:qemu_t:s0-s0:c0.c1023 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1266004735.924:260): arch=c000003e syscall=21 success=no exit=-13 a0=34318658c5 a1=4 a2=0 a3=0 items=0 ppid=1 pid=9115 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=31 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=root:system_r:qemu_t:s0-s0:c0.c1023 key=(null)
type=ANOM_ABEND msg=audit(1266004735.925:261): auid=0 uid=0 gid=0 ses=31 subj=root:system_r:qemu_t:s0-s0:c0.c1023 pid=9115 comm="qemu-kvm" sig=6
Should I clone this to a new report?
I think the fix is already in the 5.5 packages. Preview available on people.redhat.com/dwalsh/SELinux/RHEL5 |
sealert output follows, hostname masked. Summary: SELinux is preventing qemu-kvm (svirt_t) "read" random_device_t. Detailed Description: SELinux denied access requested by qemu-kvm. It is not expected that this access is required by qemu-kvm and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Additional Information: Source Context system_u:system_r:svirt_t:s0:c131,c496 Target Context system_u:object_r:random_device_t:s0 Target Objects random [ chr_file ] Source qemu-kvm Source Path /usr/bin/qemu-kvm Port <Unknown> Host XXX Source RPM Packages qemu-system-x86-0.10.4-4.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-39.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name XXX Platform Linux XXX 2.6.29.3-155.fc11.x86_64 #1 SMP Wed May 20 17:43:16 EDT 2009 x86_64 x86_64 Alert Count 1 First Seen Wed Jun 10 13:07:27 2009 Last Seen Wed Jun 10 13:07:27 2009 Local ID 1260fd40-fe4d-43cf-860e-faf5480f0251 Line Numbers Raw Audit Messages node=XXX type=AVC msg=audit(1244632047.660:519): avc: denied { read } for pid=25943 comm="qemu-kvm" name="random" dev=tmpfs ino=533 scontext=system_u:system_r:svirt_t:s0:c131,c496 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file node=XX type=SYSCALL msg=audit(1244632047.660:519): arch=c000003e syscall=21 success=no exit=-13 a0=3a80466448 a1=4 a2=0 a3=0 items=0 ppid=1 pid=25943 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=30 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c131,c496 key=(null) Effect: QEMU/KVM virtual machines cannot start while VNC TLS support is enabled in /etc/libvirt/qemu.conf, error message in /var/log/libvirt/qemu/HOSTNAME.log: "Fatal: no entropy gathering module detected". Interestingly, according to fuser libvirtd itself uses /dev/urandom which it is allowed to access; qemu-kvm wants /dev/random so enabling global_ssp is useless since it covers urandom_device_t only, effectively turning this issue into a blocker IMO. Additional information ====================== Custom /etc/libvirt/qemu.conf directives: vnc_listen = "0.0.0.0" vnc_tls = 1 vnc_tls_x509_verify = 1 virt-* connections via qemu+tls:// to the affected system work flawlessly. Required key/cert/ca files are in place as described at http://virt-manager.et.redhat.com/page/RemoteTLS#KVM_VNC_Server