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

[Michal Prívozník]

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. We should
rather fix this properly, if we can.

Michal