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 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. Here's the results of a few different relabelling strategies: In the case of Stefano's patch where libvirt's relabelling is completely removed (it just calls virCommandRun() directly), the passt process looks like this: unconfined_u:unconfined_r:passt_t:s0-s0:c0.c1023 97132 When I allow libvirt to do its normal relabelling, it ends up like this: unconfined_u:unconfined_r:svirt_t:s0:c239,c560 104213 When I run it with my patch (which calls getfilecon, then adds the MCS), it looks like this: system_u:object_r:passt_exec_t:s0:c239,c560 Am I correct to think that what everyone is suggesting is that the process ends up like this? (it's what would happen with Stefano's hard-coded hack that this message is replying to): unconfined_u:unconfined_r:passt_t:s0:c239,c560 104213 If so, how are we to derive "passt_t" from "passt_exec_t", since both those names are arbritrary, and some other selinux policy for some other binary might choose names that don't simply differ by having "_exec" added/removed. Is it possible to get the label of the process after it has been forked, and grab the context type from there?