libvirt cannot kill dhcp in containers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
isc-dhcp (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
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(140198365
Jun 5 17:54:14 t1 kernel: [ 2563.660491] type=1400 audit(140198365
Jun 5 17:54:14 t1 kernel: [ 2563.660600] type=1400 audit(140198365
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.
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: profile_ name},
# Allow unconfined processes to send us signals by default
signal (receive) peer=unconfined,
# Allow us to signal ourselves
signal peer=@{
# 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.