Comment 1 for bug 1326865

libvirt-lxc should start containers in a container policy, but I guess these needs probably significant upstream work since libvirt-lxc and lxc are not the same project.

The way signals work with AppArmor is that there are two checks-- can the sending process send a signal to another process and can the target process receive the signal from the sending process. The AppArmor base abstraction has the following:
  # Allow unconfined processes to send us signals by default
  signal (receive) peer=unconfined,
  # Allow us to signal ourselves
  signal peer=@{profile_name},
  # Checking for PID existence is quite common so add it by default for now
  signal (receive, send) set=("exists"),

In the case of libvirt-lxc and dhclient, libvirtd runs under confinement so the 'peer' is not 'unconfined' but rather the AppArmor label (in this case, /usr/sbin/libvirtd) which is why we have the denial.

In thinking about this more, we will have a similar issue with any confined process in the container (eg, mysql). Perhaps the best way forward is to not run libvirtd under confinement at all. Historically we did this because change_profile could not be done by a process that was unconfined-- I believe this requirement is lifted now. The current policy for libvirt is extremely permissive and offers very little protection anyway.