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

Daniel P. Berrangé berrange at redhat.com
Mon Mar 6 09:03:42 UTC 2023


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:
> > > On Fri, Mar 03, 2023 at 06:06:05PM +0000, Daniel P. Berrangé wrote:
> > > > On Fri, Mar 03, 2023 at 09:56:55AM -0800, Andrea Bolognani wrote:
> > > > > Right, but wouldn't the idea of poking at the filesystem to retrieve
> > > > > the label from the binary (passt_exec_t) and then applying a text
> > > > > transformation to obtain the runtime label (passt_t) go directly
> > > > > against the idea of not hardcoding information about a specific
> > > > > policy implementation into libvirt?
> > > > 
> > > > I'm not suggesting applying a text transformation. The example code
> > > > using libselinux I described in the other reply actually askes the
> > > > kernel to tell us what the target type will be when a process
> > > > labelled passt_exec_t is execd.
> > > 
> > > Yeah, that's a lot better.
> > > 
> > > > > As I understand it, such a policy would allow virtqemud (virtd_t) to
> > > > > execute passt (passt_exec_t) and automatically result in a transition
> > > > > of the process to the desired context (passt_t).
> > > > 
> > > > Yes, and I'm saying we must ask the kernel to tell us what that target
> > > > context will be for the loaded policy, given the source file context.
> > > 
> > > 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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


More information about the libvir-list mailing list