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

Laine Stump laine at redhat.com
Wed Feb 22 14:59:40 UTC 2023


On 2/22/23 9:30 AM, Daniel P. Berrangé 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.

As the person who started all this by naively believing that we would 
just need to "add something to the selinux-policy package" to make 
selinux+libvirt+passt work, and now that Stefano has done the heavy 
lifting to figure out something that actually *does* work, I will say 
that I'll help in whatever way I can to make that happen in as short a 
time as possible.



More information about the libvir-list mailing list