apparmor, libvirt-qemu: Allow macvtap access

[Christian Ehrhardt ]

apparmor, libvirt-qemu: Allow macvtap access

Add rule to allow access to /dev/tap* used by macvtap.

SubmissionInfo: should be fixed via virt-aa-helper

Old Bug-Ubuntu: https://bugs.launchpad.net/bugs/921870

[Christian Ehrhardt  (paelzer)]

I found two styles to define, the latter being the more common one I knew.
Testing both to be sure.

1. macvtap via forward mode bridge network
<network>
  <name>macvtap-net</name>
  <uuid>157ecf3d-14fc-4157-ace9-9c7c05597252</uuid>
  <forward dev='eno2' mode='bridge'>
    <interface dev='eno2'/>
  </forward>
</network>

Then in the guest
    <interface type='network'>
      <source network='macvtap-net'/>
      <model type='virtio'/>
    </interface>

2. macvtap via direct guest interface
   <interface type='direct' >
       <source dev='eno3'/>
   </interface>

Both work nowadays.

This already generates (changing as needed):
/etc/apparmor.d/libvirt/libvirt-26dedac7-b8de-4772-9f59-a5bb962394c5.files:15: "/dev/tap12" rw,
/etc/apparmor.d/libvirt/libvirt-26dedac7-b8de-4772-9f59-a5bb962394c5.files:16: "/dev/tap13" rw,

This is actually doen since ages via domainSetSecurityTapFDLabel -> AppArmorSetFDLabel.
Time to drop the following patch next merge:
  0002-apparmor-libvirt-qemu-Allow-macvtap-access.patch:+ /dev/tap* rw,

[Christian Ehrhardt  (paelzer)]

This bug is completed with this analysis - I added a card to the 18.04 merge tasks to remember there to drop it.