Summary: SELinux is preventing /usr/bin/qemu-kvm "read" access on random. Detailed Description: [SELinux is in permissive mode. This access was not denied.] 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. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:svirt_t:s0:c154,c495 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 (removed) Source RPM Packages qemu-system-x86-0.11.0-11.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-46.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name (removed) Platform Linux vmh002.clone1.com 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 Alert Count 1 First Seen Sun 29 Nov 2009 10:20:28 PM CST Last Seen Sun 29 Nov 2009 10:20:28 PM CST Local ID bc8dbc57-0e8a-4106-acd2-6a1399ad70fb Line Numbers Raw Audit Messages node=vmh002.clone1.com type=AVC msg=audit(1259554828.172:300): avc: denied { read } for pid=12794 comm="qemu-kvm" name="random" dev=tmpfs ino=3291 scontext=system_u:system_r:svirt_t:s0:c154,c495 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file node=vmh002.clone1.com type=SYSCALL msg=audit(1259554828.172:300): arch=c000003e syscall=21 success=yes exit=0 a0=34f0865f48 a1=4 a2=0 a3=0 items=0 ppid=1 pid=12794 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c154,c495 key=(null) Hash String generated from selinux-policy-3.6.32-46.fc12,catchall,qemu-kvm,svirt_t,random_device_t,chr_file,read audit2allow suggests: #============= svirt_t ============== allow svirt_t random_device_t:chr_file read;
This access violation likely happens because qemu is trying to generate a session key for vnc access over tls.
Actually, to be precise, the access violation happens when a vnc connection is opened to a virtual machine using tls from a remote system.
Any chance of getting qemu to use urand instead of rand? Or is this caused by a library that qemu is calling into?
Comment #1 indicates that the reporter has configured VNC to use TLS. We're just using GNUTLS for this in QEMU. GNUTLS uses gcrypt, which allows use of /dev/random or /dev/urandom, but GNUTLS always tells it to use /dev/random for generating keys.
Ok, Richard if you want to use this alternative, I think it is better you use a custom policy. You can add these rules for now using # grep random /var/log/audit/audit.log | audit2allow -M mysvirt # semodule -i mysvirt.pp
That solves the problem, of course. Obviously, it would be *nice* if this work-around were not needed. The use of vnc over tls is likely a very common set up. But, I understand the issue with the GNUTLS library. Thank you all for your timely responses.