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

> 
> 1) it is unable to write a pidfile to /var/run/libvirt/qemu/passt because
> its selinux policies restrict it /var/run/$UID for pidfiles (since that's
> where the pidfiles are expected by unprivileged libvirt).
> 
> 2) it can't write to a logFile in /tmp, because passt's selinux policy
> restricts it to $HOME of the uid passt is run under (which is problematic
> since the user "qemu" doesn't have a $HOME :-))

Nothing must ever write to /tmp, so definitely needs fixing to use a
per-VM log location.

> 3) No <portForward>s are possible, because the passt selinux policy forbids
> them.

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