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

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