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?)
