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

[Andrea Bolognani]

On Mon, Mar 06, 2023 at 09:03:42AM +0000, Daniel P. Berrangé wrote:
> 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.

Got it! The MCS bit is indeed the part that I had been missing.

-- 
Andrea Bolognani / Red Hat / Virtualization