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