[PATCH] security: Add support for SUSE edk2 firmware paths

Andrea Bolognani abologna at redhat.com
Thu Mar 2 14:43:24 UTC 2023


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

  Reviewed-by: Andrea Bolognani <abologna at redhat.com>

but perhaps it would be a good idea to consider migrating edk2 images
to their own directory long term?

-- 
Andrea Bolognani / Red Hat / Virtualization



More information about the libvir-list mailing list