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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1326865
Title:
libvirt cannot kill dhcp in containers
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1326865/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
