network in vhostuser server mode not hot-addable due to apparmor
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| libvirt (Ubuntu) |
Triaged
|
Medium
|
Unassigned | ||
| Bionic |
Won't Fix
|
Undecided
|
Unassigned | ||
| Disco |
Won't Fix
|
Undecided
|
Unassigned | ||
| Eoan |
Won't Fix
|
Undecided
|
Unassigned | ||
Bug Description
$ cat > vhostuser-
<interface type='vhostuser'>
<source type='unix' path='/run/test' mode='server'/>
<model type='virtio'/>
<driver queues='2'>
<host mrg_rxbuf='on'/>
</driver>
</interface>
EOF
$ virsh attach-device <anyguest> vhostuser-
Expect:
- qemu gets sec label added
- qemu creates the new path
Happens:
- qemu gets no apparmor label for the path
- qemu is blocked to create the server socket
Works:
- static attachment (virt-aa-helper will render the apparmor rule)
Workaround:
- use overrides to allow the base path to be accessed via /etc/apparmor.
TODO:
- debug libvirt while doing the hot-add and check if it uses already any security labeling calls
- if it does but apparmor is missing implement their backend
- if they don't then we need to add a labelling call for the path attribute of any interface that carrys a type=unix source
| Christian Ehrhardt (paelzer) wrote | #1 |
| Changed in libvirt (Ubuntu): | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| Changed in libvirt (Ubuntu Disco): | |
| status: | New → Won't Fix |
| Changed in libvirt (Ubuntu Eoan): | |
| status: | New → Won't Fix |
| Changed in libvirt (Ubuntu Bionic): | |
| status: | New → Won't Fix |
This would be nice to have, but the overall prio is rather low for now.
Once we know the changes needed we can decide on backportability to at least Bionic.
Next step as outlined above is debugging which (if any) security labeling calls are already triggered.