[libvirt] I have no idea why the current version of libvirt works for anyone in enforcing mode.
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions, #============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read; Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies. I believe you need to run without sound if you are running as root.
On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions,
#============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read;
Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies.
I believe you need to run without sound if you are running as root.
That sounds wrong. I would assume that the access to audio is allowed to whoever owns the console, so the check should not be whether the code runs as root or foo but if the current user for that code has those permissions. I.e. if user foo uses the console but user bar ssh to the box and starts a new domain, that check would just not work. On the other hand if you are logged on the console as root I don't see why that test should be applied. Can't you extract from SELinux if you have the access instead ? And pulseaudio should not crash in the first place ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions,
#============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read;
Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies.
I don't see it crashing - when I run with a guest with a sound device attached, I see the AVC denials, and QEMU just carries on without a active sound backend AFAICT.
I believe you need to run without sound if you are running as root.
We can't disable sound unconditonally for root, because not everyone will be using SELinux so its still valid to allow sound cards. I think the focus has to be on stopping QEMU from crashing. It might actually be an SDL bug, rather than a QEMU bug, because I believe its SDL that is responsible for opening the sound devices. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions,
#============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read;
Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies.
I don't see it crashing - when I run with a guest with a sound device attached, I see the AVC denials, and QEMU just carries on without a active sound backend AFAICT.
I believe you need to run without sound if you are running as root.
We can't disable sound unconditonally for root, because not everyone will be using SELinux so its still valid to allow sound cards. I think the focus has to be on stopping QEMU from crashing. It might actually be an SDL bug, rather than a QEMU bug, because I believe its SDL that is responsible for opening the sound devices.
Daniel How about if we check if you are running with svirt then don't execute
On 03/13/2009 06:19 AM, Daniel P. Berrange wrote: the code. Since I do not want to deal with these avc messages. Either they will happen always and I have to dontaudit them in which case a compromised svirt attacking the /root directory would be dontaudited, or people are going to see avc's all the time.
On Fri, Mar 13, 2009 at 09:44:15AM -0400, Daniel J Walsh wrote:
On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions,
#============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read;
Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies.
I don't see it crashing - when I run with a guest with a sound device attached, I see the AVC denials, and QEMU just carries on without a active sound backend AFAICT.
I believe you need to run without sound if you are running as root.
We can't disable sound unconditonally for root, because not everyone will be using SELinux so its still valid to allow sound cards. I think the focus has to be on stopping QEMU from crashing. It might actually be an SDL bug, rather than a QEMU bug, because I believe its SDL that is responsible for opening the sound devices.
Daniel How about if we check if you are running with svirt then don't execute
On 03/13/2009 06:19 AM, Daniel P. Berrange wrote: the code. Since I do not want to deal with these avc messages. Either they will happen always and I have to dontaudit them in which case a compromised svirt attacking the /root directory would be dontaudited, or people are going to see avc's all the time.
For that scenario I think it'd be better to make virt-manager prevent addition of sound hardware, since its in a position to give feedback to the user telling them why sound devices aren't allowed. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Mar 13, 2009 at 09:44:15AM -0400, Daniel J Walsh wrote:
On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions,
#============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read;
Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies. I don't see it crashing - when I run with a guest with a sound device attached, I see the AVC denials, and QEMU just carries on without a active sound backend AFAICT.
I believe you need to run without sound if you are running as root. We can't disable sound unconditonally for root, because not everyone will be using SELinux so its still valid to allow sound cards. I think the focus has to be on stopping QEMU from crashing. It might actually be an SDL bug, rather than a QEMU bug, because I believe its SDL that is responsible for opening the sound devices.
Daniel How about if we check if you are running with svirt then don't execute
On 03/13/2009 06:19 AM, Daniel P. Berrange wrote: the code. Since I do not want to deal with these avc messages. Either they will happen always and I have to dontaudit them in which case a compromised svirt attacking the /root directory would be dontaudited, or people are going to see avc's all the time.
For that scenario I think it'd be better to make virt-manager prevent addition of sound hardware, since its in a position to give feedback to the user telling them why sound devices aren't allowed.
Daniel Well there is no protocol currently to tell virt-manager that the
On 03/13/2009 09:49 AM, Daniel P. Berrange wrote: libvirt is running with svirt. I tried to remove a audio device via virt-manager and it does nothing. Also what happens when virt-manager configures a remote libvirt? Does the sound card automatically get added?
Daniel J Walsh wrote:
On Fri, Mar 13, 2009 at 09:44:15AM -0400, Daniel J Walsh wrote:
On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions,
#============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read;
Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies. I don't see it crashing - when I run with a guest with a sound device attached, I see the AVC denials, and QEMU just carries on without a active sound backend AFAICT.
I believe you need to run without sound if you are running as root. We can't disable sound unconditonally for root, because not everyone will be using SELinux so its still valid to allow sound cards. I think the focus has to be on stopping QEMU from crashing. It might actually be an SDL bug, rather than a QEMU bug, because I believe its SDL that is responsible for opening the sound devices.
Daniel How about if we check if you are running with svirt then don't execute
On 03/13/2009 06:19 AM, Daniel P. Berrange wrote: the code. Since I do not want to deal with these avc messages. Either they will happen always and I have to dontaudit them in which case a compromised svirt attacking the /root directory would be dontaudited, or people are going to see avc's all the time. For that scenario I think it'd be better to make virt-manager prevent addition of sound hardware, since its in a position to give feedback to the user telling them why sound devices aren't allowed.
Daniel Well there is no protocol currently to tell virt-manager that the
On 03/13/2009 09:49 AM, Daniel P. Berrange wrote: libvirt is running with svirt. I tried to remove a audio device via virt-manager and it does nothing. Also what happens when virt-manager configures a remote libvirt? Does the sound card automatically get added?
What does 'does nothing' mean? We can't hotunplug a sound card, you will need to restart the VM for the changes to take effect. virt-manager out of the box does not add a sound card for remote VMs, only local. The default can be changed via Edit->Preferences. - Cole
On 03/13/2009 11:16 AM, Cole Robinson wrote:
Daniel J Walsh wrote:
On Fri, Mar 13, 2009 at 09:44:15AM -0400, Daniel J Walsh wrote:
On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions,
#============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read;
Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies. I don't see it crashing - when I run with a guest with a sound device attached, I see the AVC denials, and QEMU just carries on without a active sound backend AFAICT.
I believe you need to run without sound if you are running as root. We can't disable sound unconditonally for root, because not everyone will be using SELinux so its still valid to allow sound cards. I think the focus has to be on stopping QEMU from crashing. It might actually be an SDL bug, rather than a QEMU bug, because I believe its SDL that is responsible for opening the sound devices.
Daniel How about if we check if you are running with svirt then don't execute
On 03/13/2009 06:19 AM, Daniel P. Berrange wrote: the code. Since I do not want to deal with these avc messages. Either they will happen always and I have to dontaudit them in which case a compromised svirt attacking the /root directory would be dontaudited, or people are going to see avc's all the time. For that scenario I think it'd be better to make virt-manager prevent addition of sound hardware, since its in a position to give feedback to the user telling them why sound devices aren't allowed.
Daniel Well there is no protocol currently to tell virt-manager that the
On 03/13/2009 09:49 AM, Daniel P. Berrange wrote: libvirt is running with svirt. I tried to remove a audio device via virt-manager and it does nothing. Also what happens when virt-manager configures a remote libvirt? Does the sound card automatically get added?
What does 'does nothing' mean? We can't hotunplug a sound card, you will need to restart the VM for the changes to take effect.
virt-manager out of the box does not add a sound card for remote VMs, only local. The default can be changed via Edit->Preferences.
- Cole
On a running vm, I tried to remove the sound card and nothing happened. I just tried again on a stopped vm and it got removed. If it is not able to remove the sound card on a running VM, then the remove button should be greyed out or it should remove it from the XML and explain to me it will happen on the next restart of the VM.
Daniel J Walsh wrote:
On 03/13/2009 11:16 AM, Cole Robinson wrote:
Daniel J Walsh wrote:
Well there is no protocol currently to tell virt-manager that the libvirt is running with svirt. I tried to remove a audio device via virt-manager and it does nothing. Also what happens when virt-manager configures a remote libvirt? Does the sound card automatically get added?
What does 'does nothing' mean? We can't hotunplug a sound card, you will need to restart the VM for the changes to take effect.
virt-manager out of the box does not add a sound card for remote VMs, only local. The default can be changed via Edit->Preferences.
- Cole
On a running vm, I tried to remove the sound card and nothing happened. I just tried again on a stopped vm and it got removed. If it is not able to remove the sound card on a running VM, then the remove button should be greyed out or it should remove it from the XML and explain to me it will happen on the next restart of the VM.
virt-manager will show a warning to the effect of 'This device will be removed after the next VM shutdown' if it can't hot unplug, and has done so for awhile. Certainly works for me with virt-manager-0.7.0 on rawhide. If you can reproduce, please file a bug with ~/.virt-manager/virt-manager.log Thanks, Cole
On Fri, Mar 13, 2009 at 10:50:04AM -0400, Daniel J Walsh wrote:
How about if we check if you are running with svirt then don't execute the code. Since I do not want to deal with these avc messages. Either they will happen always and I have to dontaudit them in which case a compromised svirt attacking the /root directory would be dontaudited, or people are going to see avc's all the time.
For that scenario I think it'd be better to make virt-manager prevent addition of sound hardware, since its in a position to give feedback to the user telling them why sound devices aren't allowed.
Daniel Well there is no protocol currently to tell virt-manager that the libvirt is running with svirt. I tried to remove a audio device via virt-manager and it does nothing. Also what happens when virt-manager configures a remote libvirt? Does the sound card automatically get added?
I was thinking virt-manager could call 'virNodeGetSecurityModel' to see if the 'selinux' security model was active on the host it was talking to. Or similar information from the capabilities XML for the host Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Mar 13, 2009 at 10:19:44AM +0000, Daniel P. Berrange wrote:
On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions,
#============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read;
Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies.
I don't see it crashing - when I run with a guest with a sound device attached, I see the AVC denials, and QEMU just carries on without a active sound backend AFAICT.
FYI I can now reproduce the problem and there's lots of things going on here :-( First, QEMU isn't crashing, libvirtd is killing it because it hangs. It is hanging because pulseaudio can't startup, and a bug in pulseaudio causes it to then get stuck on a condition variable wait that is never notified. THis causes the whole QEMU I/O loop to hang. Pulseaudio has this idea of a 'system instance' which the admin can start to provide a permanently active daemon, thus avoiding the need to autostart. This isn't setup to work at all in Fedora though, and there's no obvious way to disable autostart either :-( In theory though, if we could get autostart to be disabled, then we could allow QEMU access to the shared 'system instance' of PulseAudio just by making the SELinux policy allow connection to its UNIX domain socket in /var/run/. It still tries to create some junk in /root/ even when using the system instance which it really needs to not do. That said it seems to be OK if this stuff fails and still connects to the daemon.
I believe you need to run without sound if you are running as root.
We can't disable sound unconditonally for root, because not everyone will be using SELinux so its still valid to allow sound cards. I think the focus has to be on stopping QEMU from crashing. It might actually be an SDL bug, rather than a QEMU bug, because I believe its SDL that is responsible for opening the sound devices.
I'm going to commit the following temporary patch to Fedora 11 rawhide libvirt builds only, to disable sound cards when SELinux is active and running as root. This will avoid the AVC denials, while we spend more time trying to get PA 'system instance' to work better, without autostart Index: src/qemu_conf.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_conf.c,v retrieving revision 1.138 diff -u -p -r1.138 qemu_conf.c --- src/qemu_conf.c 16 Mar 2009 13:54:26 -0000 1.138 +++ src/qemu_conf.c 17 Mar 2009 15:50:10 -0000 @@ -757,6 +757,20 @@ int qemudBuildCommandLine(virConnectPtr char uuid[VIR_UUID_STRING_BUFLEN]; char domid[50]; char *pidfile; + int skipSound = 0; + + if (driver->securityDriver && + driver->securityDriver->name && + STREQ(driver->securityDriver->name, "selinux") && + getuid() == 0) { + static int soundWarned = 0; + skipSound = 1; + if (vm->def->nsounds && + !soundWarned) { + soundWarned = 1; + VIR_WARN0("Sound cards for VMs are disabled while SELinux security model is active"); + } + } uname_normalize(&ut); @@ -1364,7 +1378,8 @@ int qemudBuildCommandLine(virConnectPtr } /* Add sound hardware */ - if (vm->def->nsounds) { + if (vm->def->nsounds && + !skipSound) { int size = 100; char *modstr; if (VIR_ALLOC_N(modstr, size+1) < 0) -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 03/17/2009 11:52 AM, Daniel P. Berrange wrote:
On Fri, Mar 13, 2009 at 10:19:44AM +0000, Daniel P. Berrange wrote:
On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
Libvirt is executing qemu requiring it to execute pulseaudio which would require the folowing permissions,
#============= svirt_t ============== allow svirt_t admin_home_t:dir setattr; allow svirt_t admin_home_t:file { read write }; allow svirt_t pulseaudio_port_t:tcp_socket name_connect; allow svirt_t svirt_tmpfs_t:file read; allow svirt_t user_tmpfs_t:file read;
Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes and qemu dies. I don't see it crashing - when I run with a guest with a sound device attached, I see the AVC denials, and QEMU just carries on without a active sound backend AFAICT.
FYI I can now reproduce the problem and there's lots of things going on here :-(
First, QEMU isn't crashing, libvirtd is killing it because it hangs.
It is hanging because pulseaudio can't startup, and a bug in pulseaudio causes it to then get stuck on a condition variable wait that is never notified. THis causes the whole QEMU I/O loop to hang.
Pulseaudio has this idea of a 'system instance' which the admin can start to provide a permanently active daemon, thus avoiding the need to autostart. This isn't setup to work at all in Fedora though, and there's no obvious way to disable autostart either :-( In theory though, if we could get autostart to be disabled, then we could allow QEMU access to the shared 'system instance' of PulseAudio just by making the SELinux policy allow connection to its UNIX domain socket in /var/run/.
It still tries to create some junk in /root/ even when using the system instance which it really needs to not do. That said it seems to be OK if this stuff fails and still connects to the daemon.
I believe you need to run without sound if you are running as root. We can't disable sound unconditonally for root, because not everyone will be using SELinux so its still valid to allow sound cards. I think the focus has to be on stopping QEMU from crashing. It might actually be an SDL bug, rather than a QEMU bug, because I believe its SDL that is responsible for opening the sound devices.
I'm going to commit the following temporary patch to Fedora 11 rawhide libvirt builds only, to disable sound cards when SELinux is active and running as root. This will avoid the AVC denials, while we spend more time trying to get PA 'system instance' to work better, without autostart
Index: src/qemu_conf.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_conf.c,v retrieving revision 1.138 diff -u -p -r1.138 qemu_conf.c --- src/qemu_conf.c 16 Mar 2009 13:54:26 -0000 1.138 +++ src/qemu_conf.c 17 Mar 2009 15:50:10 -0000 @@ -757,6 +757,20 @@ int qemudBuildCommandLine(virConnectPtr char uuid[VIR_UUID_STRING_BUFLEN]; char domid[50]; char *pidfile; + int skipSound = 0; + + if (driver->securityDriver&& + driver->securityDriver->name&& + STREQ(driver->securityDriver->name, "selinux")&& + getuid() == 0) { + static int soundWarned = 0; + skipSound = 1; + if (vm->def->nsounds&& + !soundWarned) { + soundWarned = 1; + VIR_WARN0("Sound cards for VMs are disabled while SELinux security model is active"); + } + }
uname_normalize(&ut);
@@ -1364,7 +1378,8 @@ int qemudBuildCommandLine(virConnectPtr }
/* Add sound hardware */ - if (vm->def->nsounds) { + if (vm->def->nsounds&& + !skipSound) { int size = 100; char *modstr; if (VIR_ALLOC_N(modstr, size+1)< 0)
Looks good to me.
participants (4)
-
Cole Robinson -
Daniel J Walsh -
Daniel P. Berrange -
Daniel Veillard