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]
[1]:
https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abst...
[2]:
https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abst...
[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 | 20 ++++++++++++++++++-
2 files changed, 22 insertions(+), 1 deletion(-)
--
2.17.1