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

[Jim Fehlig]

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 at redhat.com>
> 
> 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