Setting up a bridge device the virt-manager way:
1. "specify shared device name"
name: virbr0
(that is the name of the default bridge in -c qemu:///user and not visible to qemu:///session)
The profile applies and blocks
Unable to complete install: 'internal error: /usr/lib/qemu/qemu-bridge-helper --use-vnet --br=virbr0 --fd=24: failed to communicate with bridge helper: Transport endpoint is not connected
stderr=failed to open /dev/net/tun: Permission denied
I see, this is the mediation of signals and sockets kicking in, that wasn't existing back then.
Rules needed for those are:
--- usr.sbin.libvirtd.orig 2018-04-04 07:40:24.814316241 +0000
+++ usr.sbin.libvirtd.new 2018-04-04 08:12:44.734708742 +0000
@@ -73,6 +73,11 @@
# required if guests run unconfined seclabel type='none' but libvirtd is confined
signal (read, send) peer=unconfined,
+ # for qemu-bridge-helper
+ #unix (send) type=stream addr=none peer=/usr/sbin/libvirtd/qemu_bridge_helper,
+ unix (send, receive) type=stream addr=none peer=(label=/usr/sbin/libvirtd//qemu_bridge_helper),
+ signal (send) set=("term") peer=/usr/sbin/libvirtd//qemu_bridge_helper,
+
# Very lenient profile for libvirtd since we want to first focus on confining
# the guests. Guests will have a very restricted profile.
/ r,
@@ -121,6 +126,10 @@
network inet stream,
+ # Be controllable from libvirtd
+ unix (send, receive) type=stream addr=none peer=(label=/usr/sbin/libvirtd),
+ signal (receive) set=("term") peer=/usr/sbin/libvirtd,
+
/dev/net/tun rw,
/etc/qemu/** r,
owner @{PROC}/*/status r,
When these are resolved we obviously need still:
$ chmod u+s /usr/lib/qemu/qemu-bridge-helper
But that is expected for now.
Even after all that it doesn't work for me (also tried g+s later).
It still complains that bridge helper isn't controllable, and that it got permission denied messages.
libvirtError: internal error: /usr/lib/qemu/qemu-bridge-helper --use-vnet --br=virbr0 --fd=25: failed to communicate with bridge helper: Transport endpoint is not connected
stderr=failed to open /dev/net/tun: Permission denied
If I run it with sudo it works, so it is as if the setuid would not kick in at all for me.
Never the less, maybe my setup is broken in other ways.
@Toni - could you
1. apply the proposed appamor change above to your local file /etc/apparmor.d/usr.sbin.libvirtd
2. reload the profile "sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.libvirtd"
3. try again your case and run "dmesg -w" in a different console
=> The apparmor issues should be gone, and if you could confirm this I could start bringing it upstream
=> I'd be interested to hear if then this works for you or if you still see the permission denied issue that I see.
This isn't an super-urgent issue, so we don't have to rush it into Bionic.
If we get it working you and others affected can do the profile change until it is upstream and rebundled in an ubuntu update.
But for all of this I'd need to know if it resolves it for you now.
Running as
$ virt-manager -c qemu:///session
Setting up a bridge device the virt-manager way:
1. "specify shared device name"
name: virbr0
(that is the name of the default bridge in -c qemu:///user and not visible to qemu:///session)
The profile applies and blocks qemu/qemu- bridge- helper --use-vnet --br=virbr0 --fd=24: failed to communicate with bridge helper: Transport endpoint is not connected
Unable to complete install: 'internal error: /usr/lib/
stderr=failed to open /dev/net/tun: Permission denied
Denies (simplified): "/usr/sbin/ libvirtd/ /qemu_bridge_ helper" family="unix" sock_type="stream" requested_ mask="send receive" addr=none peer_addr=none peer="/ usr/sbin/ libvirtd"
apparmor="DENIED" profile=
apparmor="DENIED" profile= "/usr/sbin/ libvirtd" family="unix" sock_type="stream" requested_ mask="send receive" addr=none peer_addr=none peer="/ usr/sbin/ libvirtd/ /qemu_bridge_ helper"
apparmor="DENIED" profile= "/usr/sbin/ libvirtd" operation="signal" requested_ mask="send" denied_mask="send" signal=term peer="/ usr/sbin/ libvirtd/ /qemu_bridge_ helper"
apparmor="DENIED" profile= "/usr/sbin/ libvirtd/ /qemu_bridge_ helper" operation="signal" requested_ mask="receive" denied_ mask="receive" signal=term peer="/ usr/sbin/ libvirtd"
I see, this is the mediation of signals and sockets kicking in, that wasn't existing back then.
Rules needed for those are: libvirtd. orig 2018-04-04 07:40:24.814316241 +0000 libvirtd. new 2018-04-04 08:12:44.734708742 +0000
--- usr.sbin.
+++ usr.sbin.
@@ -73,6 +73,11 @@
# required if guests run unconfined seclabel type='none' but libvirtd is confined
signal (read, send) peer=unconfined,
+ # for qemu-bridge-helper sbin/libvirtd/ qemu_bridge_ helper, /usr/sbin/ libvirtd/ /qemu_bridge_ helper) , sbin/libvirtd/ /qemu_bridge_ helper,
+ #unix (send) type=stream addr=none peer=/usr/
+ unix (send, receive) type=stream addr=none peer=(label=
+ signal (send) set=("term") peer=/usr/
+
# Very lenient profile for libvirtd since we want to first focus on confining
# the guests. Guests will have a very restricted profile.
/ r,
@@ -121,6 +126,10 @@
network inet stream,
+ # Be controllable from libvirtd /usr/sbin/ libvirtd) , sbin/libvirtd,
+ unix (send, receive) type=stream addr=none peer=(label=
+ signal (receive) set=("term") peer=/usr/
+
/dev/net/tun rw,
/etc/qemu/** r,
owner @{PROC}/*/status r,
When these are resolved we obviously need still: qemu/qemu- bridge- helper
$ chmod u+s /usr/lib/
But that is expected for now.
Even after all that it doesn't work for me (also tried g+s later). qemu/qemu- bridge- helper --use-vnet --br=virbr0 --fd=25: failed to communicate with bridge helper: Transport endpoint is not connected
It still complains that bridge helper isn't controllable, and that it got permission denied messages.
libvirtError: internal error: /usr/lib/
stderr=failed to open /dev/net/tun: Permission denied
If I run it with sudo it works, so it is as if the setuid would not kick in at all for me.
Never the less, maybe my setup is broken in other ways. d/usr.sbin. libvirtd d/usr.sbin. libvirtd"
@Toni - could you
1. apply the proposed appamor change above to your local file /etc/apparmor.
2. reload the profile "sudo apparmor_parser -r /etc/apparmor.
3. try again your case and run "dmesg -w" in a different console
=> The apparmor issues should be gone, and if you could confirm this I could start bringing it upstream
=> I'd be interested to hear if then this works for you or if you still see the permission denied issue that I see.
This isn't an super-urgent issue, so we don't have to rush it into Bionic.
If we get it working you and others affected can do the profile change until it is upstream and rebundled in an ubuntu update.
But for all of this I'd need to know if it resolves it for you now.