[PATCH v2 1/3] qemu_passt: Don't make passt transition to svirt_t/libvirt_domain on start

[Stefano Brivio]

On Wed, 22 Feb 2023 14:30:21 +0000
Daniel P. Berrangé <berrange at redhat.com> 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.

-- 
Stefano