On Thu, Jan 15, 2026 at 11:14:04 +0100, Michal Prívozník wrote: > On 1/15/26 08:49, Peter Krempa wrote: > > On Thu, Jan 15, 2026 at 08:38:36 +0100, Michal Prívozník via Devel wrote: > >> On 1/14/26 20:39, Erik Huelsmann wrote: > >>> Hi Michal,
[...] > Another idea I had to fix this issue is: with AppArmor libvirt generates > basically two files (both under /etc/apparmor.d/libvirt/): > > 1) libvirt-$UUID > 2) libvirt-$UUID.files > > where the first one basically just includes abstractions/libvirt-qemu > AND libvirt-$UUID.files. The libvirt-$UUID.files then contains all those > domain specific paths, like: > > /run/libvirt/qemu/swtpm/1-guest-swtpm.sock > /var/lib/libvirt/qemu/domain-1-guest/fs0-fs.sock > > and so on (intentionally picked interesting paths to illustrate my > point). Thing is, this list of paths is constructed in two ways: > > a) in qemuProcessPrepareDomain() during qemuSecurityGenLabel() from > domain XML (we know this is problematic), > b) in qemuProcessPrepareHost() where qemuSecurityDomainSetPathLabel() > ends up executing virt-aa-helper in such fashion, that the domain XML on > its input is ignored, but desired path is appended into the > libvirt-$UUID.files. In the end, the libvirt-$UUID.files is a list of > paths with mixed sources (some come from domain XML, others from runtime > decisions). With that, it's impossible to keep the profile true. So what > if we split the file? We'd have: > > 1) libvirt-$UUID > 2) libvirt-$UUID.files > 3) libvirt-$UUID.internal > > Now, libvirt-$UUID would just include the other two files, > libvirt-$UUID.files would contain all the paths collected from domain > XML and thus can be regenerated whenever domain XML changes, and > finally, libvirt-$UUID.internal would then contain those specific, > internal paths like /var/lib/libvirt/qemu/domain-1-guest/master-key.aes > for instance. I've just reviewed some patches which tried to add some data to "status XML" for labelling with apparmor. One of the patches tried to store paths to the TAP devices we create. Now it was broken because it stored paths containing PID of virtqemud, which makes no sense because we close the FDs not long after and also changes if virtqemud restarts. Now while I think that qemu ought to have access to any FD we've passed (Thus just add everything in /proc/PID/fd/?) if more granular approach is neede we possibly could have an append-only file catching these volatile entries. Arguably it'd be less secure than with e.g. selinux where we label the FD itself and if it's closed the label vanishes, with an append-only file the FD would be always allowed. Anyways I agree that the above is not related to the case you're trying to solve here, since in this case we do store the resolved paths (from 'volume' -> path translation) internally.
