[libvirt] [PATCH] AppArmor: Allow libvirtd to kill unconfined processes
From: intrigeri <intrigeri+libvirt@boum.org> On startup libvirtd runs a number of QEMU processes unconfined such as: /usr/bin/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize libvirtd needs to be allowed to kill these processes, otherwise they remain running. --- examples/apparmor/usr.sbin.libvirtd | 1 + 1 file changed, 1 insertion(+) diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index a1083b0410..0ddec3f6e2 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -63,6 +63,7 @@ signal (send) peer=/usr/sbin/dnsmasq, signal (read, send) peer=libvirt-*, + signal (send) set=("kill") peer=unconfined, # Very lenient profile for libvirtd since we want to first focus on confining # the guests. Guests will have a very restricted profile. -- 2.15.1
On Sat, Jan 13, 2018 at 9:54 AM, <intrigeri+libvirt@boum.org> wrote:
From: intrigeri <intrigeri+libvirt@boum.org>
On startup libvirtd runs a number of QEMU processes unconfined such as:
/usr/bin/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize
libvirtd needs to be allowed to kill these processes, otherwise they remain running.
Hi intrigeri, I recently had spotted this issue and discussed on IRC but couldn't recreate after a while when I wanted to debug. But the reason and the rule totally make sense. It is a bit unfortunate as it allows random kills essentially, so if anyone is up to we might be better up to spawn those capability probers with a named profile that we can refer to here. But until then the rule here is required to not get into awkward situations. +1 from me, thanks intrigeri
--- examples/apparmor/usr.sbin.libvirtd | 1 + 1 file changed, 1 insertion(+)
diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index a1083b0410..0ddec3f6e2 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -63,6 +63,7 @@
signal (send) peer=/usr/sbin/dnsmasq, signal (read, send) peer=libvirt-*, + signal (send) set=("kill") peer=unconfined,
# Very lenient profile for libvirtd since we want to first focus on confining # the guests. Guests will have a very restricted profile. -- 2.15.1
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
Christian Ehrhardt:
I recently had spotted this issue and discussed on IRC but couldn't recreate after a while when I wanted to debug.
I've seen it the last few times I've started libvirtd.service on two different Debian sid ("unstable") systems.
But the reason and the rule totally make sense.
It is a bit unfortunate as it allows random kills essentially, so if anyone is up to we might be better up to spawn those capability probers with a named profile that we can refer to here.
Yes, this would be ideal. Sadly, this requires C programming skills so it's out of my league.
But until then the rule here is required to not get into awkward situations.
+1 from me, thanks intrigeri
Thanks :)
Hi, On Mon, Jan 15, 2018 at 07:43:56AM +0100, intrigeri wrote:
Christian Ehrhardt:
I recently had spotted this issue and discussed on IRC but couldn't recreate after a while when I wanted to debug.
I've seen it the last few times I've started libvirtd.service on two different Debian sid ("unstable") systems.
But the reason and the rule totally make sense.
It is a bit unfortunate as it allows random kills essentially, so if anyone is up to we might be better up to spawn those capability probers with a named profile that we can refer to here.
Yes, this would be ideal. Sadly, this requires C programming skills so it's out of my league.
But until then the rule here is required to not get into awkward situations.
+1 from me, thanks intrigeri
Thanks :)
Pushed now. -- Guido
participants (4)
-
Christian Ehrhardt -
Guido Günther -
intrigeri -
intrigeri+libvirt＠boum.org