On 2/22/23 16:51, Stefano Brivio wrote: > On Wed, 22 Feb 2023 14:30:21 +0000 > Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > >> On Wed, Feb 22, 2023 at 02:21:29PM +0100, Stefano Brivio wrote: >>> qemuSecurityCommandRun() causes an explicit domain transition of the >>> new process, but passt ships with its own SELinux policy, with >>> external interfaces for libvirtd, so we simply need to transition >>> from virtd_t to passt_t as passt is executed. The qemu type >>> enforcement rules have little to do with it. >>> >>> That is, if we switch to svirt_t, passt will run in the security >>> context that's intended for QEMU, which allows a number of >>> operations not needed by passt. On the other hand, with a switch >>> to svirt_t, passt won't be able to create its own PID file. >>> >>> Usage of those new interfaces is implemented by this change in >>> selinux-policy: >>> https://github.com/fedora-selinux/selinux-policy/pull/1613 >>> >>> Replace qemuSecurityCommandRun() with virCommandRun(), and explicitly >>> set the label, preserving the correct MCS range for the given VM >>> instance. This is a temporary measure: eventually, we'll need a more >>> generic and elegant mechanism for helper binaries. >> >> I'd really prefer to see the security manager used from the >> start, rather than committing code with a TODO that should >> be practical to implement straight away. > > Feel free, by all means. > > As to myself, I can't realistically implement missing parts of the > security manager code that I'm entirely unfamiliar with, and seriously > test the whole thing before the 9.1.0 release freeze, which happens to > be... today. > > So I see four alternatives: 1. accept this fix, 2. somebody else fixes > this "properly", 3. drop the passt networking back-end, 4. ship a > completely broken feature. That ship already sailed. Passt was merged in libvirt-9.0.0. We should rather fix this properly, if we can. Michal
