Further testing with opengl enabled graphics showed that we need much more rules than we initially added. Upstream apparmor has abstractions [1][2] for the majority of what we'd need, but those are in no Distribution yet so we can't rely on them. But we can add rules "like those known ones" matching what our testing shows as needed when we add a gl enabled device. There is no overly critical access opened by this, but still we continue to only add those to the guests that have gl enabled. The most "discussion worthy" part of it most likely are the wildcards into /dev/devices/... but they are rather specific and read only - furthermore retracing those in advance starting from the rendernode most likely is rather error prone, so I went with the wildcards. Example apparmor denials can be found in the launchpad bug [3] Updates in V2: - add jamies ack to patch #1 - limit the mapping rules to .so files - change the .changes rule to a deny as DAC would block it anyway [1]: https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstractions/mesa [2]: https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstractions/dri-common [3]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452 Christian Ehrhardt (2): security: aa-helper: allow virt-aa-helper to read /dev/dri security: aa-helper: generate more rules for gl devices .../apparmor/usr.lib.libvirt.virt-aa-helper | 3 +++ src/security/virt-aa-helper.c | 21 ++++++++++++++++++- 2 files changed, 23 insertions(+), 1 deletion(-) -- 2.17.1
