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

Stefano Brivio sbrivio at redhat.com
Wed Feb 22 17:19:41 UTC 2023


On Wed, 22 Feb 2023 17:38:49 +0100
Michal Prívozník <mprivozn at redhat.com> wrote:

> On 2/22/23 16:51, Stefano Brivio wrote:
> > 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.  
> 
> That ship already sailed. Passt was merged in libvirt-9.0.0.

...and isn't that a good enough reason to have it actually working in
9.1.0? I really fail to understand the reasoning here. :( Allow me to
quote from yourself:

On Thu, 16 Feb 2023 17:27:11 +0100
Michal Prívozník <mprivozn at redhat.com> wrote:

> And as we are getting close to the release I'd like to make this work
> with what we have now.

and I think this makes *a lot of sense*.

-- 
Stefano


More information about the libvir-list mailing list