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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list