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 07:56:18PM -0500, Laine Stump wrote:
> On 3/3/23 10:44 AM, Daniel P. Berrangé wrote:
> > On Fri, Mar 03, 2023 at 10:03:02AM -0500, Laine Stump wrote:
> > > On 2/23/23 5:47 AM, Daniel P. Berrangé wrote:
> > > > 
> > > > This really isn't difficult to do in the security manager IMHO. It is
> > > > just a variation on the existing virSecurityManagerSetChildProcessLabel
> > > > method, which instead of using the standard QEMU svirt_t labels, queries
> > > > the label by calling getfilecon on the binary to be execd and appending
> > > > the MCS label.
> > > 
> > > It seems it's not as simple as this.
> > > 
> > > I have an implementation of this, available at
> > > 
> > > https://gitlab.com/lainestump/libvirt/-/commits/active-passt-6
> > > 
> > > The problem with it is that it doesn't end up setting the label to passt_t.
> > > Instead, it sets it to passt_exec_t. My understanding is that, similar to
> > > many other binaries (e.g. dnsmasq), the context type of the binary file is
> > > passt_exec_t, and the rules in the policies use that as an indicator to
> > > transition the process to passt_t.
> > 
> > Oppps, yes, you are correct, I forgot about this distinction.
> > 
> > All is not lost, however, we just need to lookup the latter
> > based on the former.  This is something the libselinux.so
> > setexecfilecon() is already able todo, but that's not an
> > API that's convenient for us to use. The bit of logic
> > inside it though is easy enough
> > 
> >    rc = getcon(&mycon);
> >    if (rc < 0)
> >       goto out;
> > 
> >    rc = getfilecon(filename, &fcon);
> >    if (rc < 0)
> >       goto out;
> > 
> >    rc = security_compute_create(mycon, fcon, string_to_security_class("process"), &newcon);
> >    if (rc < 0)
> >      goto out;
> > 
> > In this snippet of code
> > 
> >   * 'mycon' is going to be virtd_t as we're inside libvirtd
> >   * 'fcon' will get filled with passt_exec_t
> >   * After security_compute_create returns, 'newcon' will be
> >     filled with 'passt_t'.
> 
> Thanks for the example code, that will save a lot of time :-).
> 
> Something I meant to ask about in my first message but somehow didn't - what
> about the "role" and "user" part of the label? In each of my examples (which
> I see aren't in the quoted part here, but I guess you can go back to the
> previous message), the role and user are different (either
> unconfined_u:unconfined_r or system_u:object_r). I *think* we want that to
> be unconfined_u:unconfined_r, right? (In other words, we want everything to
> be the same as the "common" label (including MCS) that we normally would
> have set for the child process, but with only the "type" changed, right?)

I believe that security_compute_create will copy the role/user from the
'mycon' argument, ie it will be the same as libvirtd itself. So I think
you can mostly ignore user/role as it'll do the right thing.

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