On 3/2/23 07:43, Andrea Bolognani wrote:
On Thu, Feb 23, 2023 at 11:13:28AM -0700, Jim Fehlig wrote:+++ b/src/security/apparmor/libvirt-qemu @@ -91,7 +91,7 @@ /usr/share/proll/** r, /usr/share/qemu-efi/** r, /usr/share/qemu-kvm/** r, - /usr/share/qemu/** r, + /usr/share/qemu/** rk, /usr/share/seabios/** r, /usr/share/sgabios/** r, /usr/share/slof/** r, +++ b/src/security/virt-aa-helper.c @@ -481,6 +481,7 @@ valid_path(const char *path, const bool readonly) "/usr/share/AAVMF/", /* for AAVMF images */ "/usr/share/qemu-efi/", /* for AAVMF images */ "/usr/share/qemu-efi-aarch64/", /* for AAVMF images */ + "/usr/share/qemu/", /* SUSE path for OVMF and AAVMF images */ "/usr/lib/u-boot/", /* u-boot loaders for qemu */ "/usr/lib/riscv64-linux-gnu/opensbi" /* RISC-V SBI implementation */Having these files in /usr/share/qemu directly looks... Kinda sketchy? That directory should belong to the QEMU package. Compare with how all the other paths listed here point to directories that are specific to the firmware at hand. I don't think this really opens up any attack vectors, so
Agree. FYI, I don't know the history behind choosing that location. Probably because it contained other firmware files.
Reviewed-by: Andrea Bolognani <abologna@xxxxxxxxxx> but perhaps it would be a good idea to consider migrating edk2 images to their own directory long term?
I think so. A task for the future, when we have a dedicated edk2 maintainer. Regards, Jim
