Re: passt SELinux labelling (was: Re: [PATCH v2 1/3] qemu_passt: Don't make passt transition to svirt_t/libvirt_domain on start)

On Fri, Mar 03, 2023 at 07:46:27PM -0500, Laine Stump wrote: > On 3/3/23 1:36 PM, Daniel P. Berrangé wrote: > > On Fri, Mar 03, 2023 at 10:18:39AM -0800, Andrea Bolognani wrote: > > > I still don't understand why we can't simply execute passt and let > > > the domain transition defined in the policy take care of switching to > > > the appropriate label from us, like we do for dnsmasq and other > > > tools? Why do we need to do things differently for passt? > > > > That won't get the per-VM label applied. It will end up running > > passt_t:s0:c0.c1023, but we want it to be passt_t:s0:c342,155. > > To transition from non-MCS to MCS, you have to explicitly tell > > the kernel what to do instead of relying on the plain automatic > > transition. > > Since you've brought up dnsmasq as an example, note that the dnsmasq > processes don't have any MCS (which I guess is the right thing, since a > single dnsmasq might be used by many/any/all guests, contrasting with passt, > or the slirp-helper or tpm, which have one instance per guest device. This > does make dnsmasq a "not ideal" example when figuring out what is needed for > passt though (in some ways, but not others)(I think? I still can't claim to > fully grok all the details of this). Yes, you are correct. dbus/slirp/swtpm are better matches for the passt scenario, though they are also not useful examples since we've ignored the SELinux labeling needs in all of them, so they all undermine svirt if used.