Bug 542769 - SELinux is preventing /usr/bin/qemu-kvm "read" access on random.
Summary: SELinux is preventing /usr/bin/qemu-kvm "read" access on random.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 12
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Glauber Costa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:89ce998f21b...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-30 18:25 UTC by Richard A Lochner
Modified: 2009-11-30 20:12 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-11-30 19:53:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.