[Bug 1326865] Re: libvirt cannot kill dhcp in containers

[Jamie Strandboge]

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.

** Tags added: apparmor

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1326865

Title:
  libvirt cannot kill dhcp in containers

Status in “isc-dhcp” package in Ubuntu:
  New

Bug description:
  If I create a ubuntu container and start it as a libvirt-lxc
  container, it runs under the host dhcp profile.  Then when I try virsh
  -c lxc:/// destroy c1, libvirtd tries to kill dhcp in the container
  but fails:

  Jun  5 17:54:14 t1 kernel: [ 2563.620698] type=1400 audit(1401983654.375:28): apparmor="DENIED" operation="signal" profile="/sbin/dhclient" pid=4304 comm="libvirtd" requested_mask="receive" denied_mask="receive" signal=term peer="/usr/sbin/libvirtd"
  Jun  5 17:54:14 t1 kernel: [ 2563.660491] type=1400 audit(1401983654.415:29): apparmor="DENIED" operation="signal" profile="/sbin/dhclient" pid=4293 comm="libvirtd" requested_mask="receive" denied_mask="receive" signal=term peer="/usr/sbin/libvirtd"
  Jun  5 17:54:14 t1 kernel: [ 2563.660600] type=1400 audit(1401983654.415:30): apparmor="DENIED" operation="signal" profile="/sbin/dhclient" pid=4293 comm="libvirtd" requested_mask="receive" denied_mask="receive" signal=term peer="/usr/sbin/libvirtd"

  I don't actually understand the mechanisms here (that a profile should
  be able to refuse receiving signals), and it seems like the proper fix
  is to have libvirt-lxc start containers confined in a container
  policy, but Jamie seemed to have another solution, which would be
  great.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1326865/+subscriptions