Bug 542769

Summary:	SELinux is preventing /usr/bin/qemu-kvm "read" access on random.
Product:	[Fedora] Fedora	Reporter:	Richard A Lochner <lochner>
Component:	qemu	Assignee:	Glauber Costa <gcosta>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	berrange, dwalsh, dwmw2, gcosta, itamar, jaswinder, jforbes, markmc, mgrepl, quintela, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:	setroubleshoot_trace_hash:89ce998f21b62009f048eaf07f00f9c66c890fe80e84e3b4d8afe1935eef4e1f
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-11-30 19:53:28 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:

Description Richard A Lochner 2009-11-30 18:25:01 UTC

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;

Comment 1 Richard A Lochner 2009-11-30 18:42:12 UTC

This access violation likely happens because qemu is trying to generate a session key for vnc access over tls.

Comment 2 Richard A Lochner 2009-11-30 18:50:07 UTC

Actually, to be precise, the access violation happens when a vnc connection is opened to a virtual machine using tls from a remote system.

Comment 3 Daniel Walsh 2009-11-30 19:03:46 UTC

Any chance of getting qemu to use urand instead of rand?  Or is this caused by a library that qemu is calling into?

Comment 4 Daniel Berrangé 2009-11-30 19:30:51 UTC

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.

Comment 5 Daniel Walsh 2009-11-30 19:53:28 UTC

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

Comment 6 Richard A Lochner 2009-11-30 20:12:55 UTC

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.