Bug 454047 - SELinux is preventing libvirtd (virtd_t) "getsched" to <Unknown> (virtd_t) & (qemu_t)
SELinux is preventing libvirtd (virtd_t) "getsched" to <Unknown> (virtd_t) & ...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-04 01:03 EDT by Lawrence Lim
Modified: 2014-03-25 20:55 EDT (History)
4 users (show)

See Also:
Fixed In Version: selinux-policy-3.3.1-78.fc9.noarch
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-13 00:36:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
alert against virtd_t (2.52 KB, text/plain)
2008-07-04 01:03 EDT, Lawrence Lim
no flags Details
alert to qemu_t (2.62 KB, text/plain)
2008-07-04 01:11 EDT, Lawrence Lim
no flags Details

  None (edit)
Description Lawrence Lim 2008-07-04 01:03:11 EDT
Description of problem:
SELinux denied access requested by libvirtd. 

Version-Release number of selected component (if applicable):
ovirt-developer-appliance-0.91-1
libvirt-0.4.4-1.fc9

How reproducible:
Always

Steps to Reproduce:
1.SELinux in enforce mode
2.virsh start developer
3.
  
Actual results:
see attached selinux log

Expected results:
no SELinux warning

Additional info:
Comment 1 Lawrence Lim 2008-07-04 01:03:11 EDT
Created attachment 310991 [details]
alert against virtd_t
Comment 2 Lawrence Lim 2008-07-04 01:11:21 EDT
Created attachment 310992 [details]
alert to qemu_t
Comment 3 Daniel Veillard 2008-07-07 05:49:48 EDT
I think this really need to be fixed in the SELinux policies, and since Ovirt
is based on Fedora, that's should be in the Fedora Component. I doubt it should
be processed in the isolation of the Virtualization tools components.
So reassigning,

Daniel
Comment 4 Benjamin Kahn 2008-07-07 10:29:30 EDT
This is on Fedora 9
Comment 5 Daniel Walsh 2008-07-07 12:17:00 EDT
This is definitely fixed in selinux-policy-3.3.1-76.fc9 if not earlier.  Please
update to the latest SELinux policy.
Comment 6 Wade Mealing 2008-07-24 21:55:19 EDT
I also have a getsched avc denial for libvirtd, (also qemu), slightly different
error..

[root@macmini ~]# date
Fri Jul 25 11:52:16 EST 2008
[root@macmini ~]# rpm -q selinux-policy
selinux-policy-3.3.1-78.fc9.noarch

-- meanwhile virt-manager is run and a prebuilt domain is attempted to be started --
 
[root@macmini ~]# tail -f /var/log/messages -n 5
Jul 25 11:51:55 macmini kernel: virbr0: port 1(vnet0) entering disabled state
Jul 25 11:51:55 macmini kernel: device vnet0 left promiscuous mode
Jul 25 11:51:55 macmini kernel: virbr0: port 1(vnet0) entering disabled state
Jul 25 11:51:55 macmini setroubleshoot: SELinux is preventing libvirtd (virtd_t)
"getsched" to <Unknown> (virtd_t). For complete SELinux messages. run sealert -l
575aa5fe-4e1d-4658-b018-0c3c30a775a7
Jul 25 11:52:15 macmini wmealing: test-test
Jul 25 11:52:32 macmini kernel: device vnet0 entered promiscuous mode
Jul 25 11:52:32 macmini kernel: virbr0: port 1(vnet0) entering listening state
Jul 25 11:52:32 macmini kernel: kvm: guest NX capability removed
Jul 25 11:52:32 macmini kernel: kvm: guest NX capability removed
Jul 25 11:52:32 macmini kernel: virbr0: port 1(vnet0) entering disabled state
Jul 25 11:52:32 macmini kernel: device vnet0 left promiscuous mode
Jul 25 11:52:32 macmini kernel: virbr0: port 1(vnet0) entering disabled state
Jul 25 11:52:32 macmini setroubleshoot: SELinux is preventing libvirtd (virtd_t)
"getsched" to <Unknown> (virtd_t). For complete SELinux messages. run sealert -l
575aa5fe-4e1d-4658-b018-0c3c30a775a7

[root@macmini ~]# date
Fri Jul 25 11:52:45 EST 2008

Comment 7 Daniel Walsh 2008-07-24 22:41:22 EDT
Please send me the complete output from the sealert command
Comment 8 Xiaohong Wang 2008-07-25 05:03:07 EDT
Updated to selinux-policy-3.3.1-78.fc9.noarch, verified this issue has been fixed.

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