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
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

Denies (simplified):
apparmor="DENIED" profile="/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="/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:
--- 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.