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é]

On Fri, Mar 03, 2023 at 09:56:55AM -0800, Andrea Bolognani wrote:
> On Fri, Mar 03, 2023 at 05:15:43PM +0000, Daniel P. Berrangé wrote:
> > On Fri, Mar 03, 2023 at 09:06:38AM -0800, Andrea Bolognani wrote:
> > > > > Since we know that we're launching passt and not some other random
> > > > > helper, why can't we simply use passt_t directly here? It feels like
> > > > > that would be less prone to issues caused by accidental (or
> > > > > intentional) misconfigurations.
> > > >
> > > > That ties libvirt's code to a specific policy impl which is
> > > > not a desirable thing. Same reason we don't hardcode svirt_t
> > > > as a type for QEMU, but instead query it dynamically from
> > > > the installed policy.
> > >
> > > Do I understand correctly that this happens in
> > > virSecuritySELinuxQEMUInitialize(), by parsing the contents of the
> > > file located via a call to selinux_virtual_domain_context_path()?
> >
> > Yes.
> >
> > > Poking around at the other files present in the same directory I see
> > > various formats being used, including... XML? It looks like SELinux
> > > implements facilities for exposing arbitrary information about the
> > > active policy at well-known locations, with (I assume) the explicit
> > > purpose of enabling this kind of interaction.
> > >
> > > So wouldn't that be the way to go for passt, and other helpers too?
> > > Have SELinux expose a virtual_helpers_context file, that we can parse
> > > to figure out the appropriate labels to use for passt and friends?
> >
> > No, I don't think so. The helpers file is a bit of a special case
> > that was needed because there were multiple contexts we needed to
> > cope with for running QEMU.
> >
> > I don't see any reason not to follow what the kernel already does
> > by relying on the labelled file context.
> 
> 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. The answer we get back (passt_t)
will come from the SELinux policy that is currently loaded in the
kernel. This is doing exactly the same thing that would happen
automatically if we had a normal exec() without the MCS stuff
involved.

> 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.

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 :|