Comment 36 for bug 1890858

Tried in some setups:
- Focal
- Groovy
- Hirsute
- Focal + the virt stack of Hirsute (via https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports)

Results:
- Focal - AA-Denial+Crash
- Groovy - Ok
- Hirsute - Ok
- Focal+Vnew - AA-Denial+Crash

So the results in my test-set are somewhat indicating a fix more in the rest of the system or maybe sssd - at least for the crash that I'm seeing :-/

The crazy part comes now and somewhat matches the mixed feedback I was getting from users on this bug. For example I was able to avoid the issue by adding the rule:
  echo "network unix dgram," | sudo tee -a /etc/apparmor.d/local/usr.sbin.libvirtd
  sudo apparmor_parser -r -W -T /etc/apparmor.d/usr.sbin.libvirtd
  sudo systemctl restart libvirtd # not strictly required, but to be sure
But then removing the issue does not bring it back (Neither the denial nor the crash).

I wondered if libvirt might cache something and only reach out (denied and broken) to nss/sssd if not present. In that case the apparmor rule would be needed to allow that.

Trying to clear anything old to get back into the error state:
  echo "" | sudo tee /etc/apparmor.d/local/usr.sbin.libvirtd
  sudo apparmor_parser -r -W -T /etc/apparmor.d/usr.sbin.libvirtd
  sudo apt remove --purge libvirt-daemon
  sudo apt install libvirt-daemon-system

And that worked to get it back to broken state.
I don't see/know yet what fixed it in >=Groovy, but it isn't the same apparmor rule that we use here.
Therefore it makes no sense applying the rule forward upstream or in new releases, but it might be a great avoidance for anyone affected to apply it in Focal's libvirt.

We now have:
- a repro case
- a clear scope (just Focal, fixed later and not a problem before)
- the libvirt profile being lenient before
- libvirt is meant to be able to bind unix sockets

I'll ask security if that is concerned to be a problem.