Hi,

I was notified that the latest patches for libvirt DAC isolation is causing some regression issues. I'm working on fixes for it but I have some doubts of how I should handle some scenarios. I'd appreciate some suggestions:

* Item 3.2: this is a test case that uses only SELinux driver, but seclabels for both DAC and SELinux are dumped in guest's XML. Before my patches, libvirt already made use of DAC driver when running in privileged mode, but this wasn't reflected in guest's XML. I tried to keep the same behavior and libvirt still adds DAC driver when running in privileged mode, but I didn't realize this would impact in guest's XML. So, I'm thinking about two alternatives:

 1. Simply do not add the DAC driver when running in privileged mode.
2. Keep it as it is. Probably applications that parse guest's XML will continue to run without problems if they just consider the first security label.

* Item 4.1: an error is issued because model is not defined for a seclabel inside a device definition. model is used to differentiate each label and should only be required when more than one security driver is used. The problem here is related to the one in item 3.2, DAC was implicitly added because libvirt is running in privileged mode and so we have 2 drivers in use.

I can use the order that seclabels appears in XML to match with the order that security drivers appears in qemu.conf to avoid this kind of error. What do you think of this solution?

Regards,
Marcelo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to