On 1/15/26 11:24, Peter Krempa wrote:
> 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.
I've seen those patches and I plan onto reviewing them, but mind you -
virt-aa-helper is fed live XML, NOT status XML:
static int
load_profile(virSecurityManager *mgr G_GNUC_UNUSED,
const char *profile,
virDomainDef *def,
const char *fn,
bool append)
{
...
if (virDomainDefFormatInternal(def, NULL, &buf,
VIR_DOMAIN_DEF_FORMAT_SECURE |
VIR_DOMAIN_DEF_FORMAT_VOLUME_TRANSLATED) < 0)
return -1;
xml = virBufferContentAndReset(&buf);
...
cmd = virCommandNewArgList(VIRT_AA_HELPER,
create ? "-c" : "-r",
"-u", profile, NULL);
...
virCommandSetInputBuffer(cmd, xml);
return virCommandRun(cmd, NULL);
}
Anyway, let's have this discussion there.
Michal
