On Fri, Mar 03, 2023 at 09:56:55AM -0800, Andrea Bolognani wrote: > On Fri, Mar 03, 2023 at 05:15:43PM +0000, Daniel P. Berrangé wrote: > > On Fri, Mar 03, 2023 at 09:06:38AM -0800, Andrea Bolognani wrote: > > > > > Since we know that we're launching passt and not some other random > > > > > helper, why can't we simply use passt_t directly here? It feels like > > > > > that would be less prone to issues caused by accidental (or > > > > > intentional) misconfigurations. > > > > > > > > That ties libvirt's code to a specific policy impl which is > > > > not a desirable thing. Same reason we don't hardcode svirt_t > > > > as a type for QEMU, but instead query it dynamically from > > > > the installed policy. > > > > > > Do I understand correctly that this happens in > > > virSecuritySELinuxQEMUInitialize(), by parsing the contents of the > > > file located via a call to selinux_virtual_domain_context_path()? > > > > Yes. > > > > > Poking around at the other files present in the same directory I see > > > various formats being used, including... XML? It looks like SELinux > > > implements facilities for exposing arbitrary information about the > > > active policy at well-known locations, with (I assume) the explicit > > > purpose of enabling this kind of interaction. > > > > > > So wouldn't that be the way to go for passt, and other helpers too? > > > Have SELinux expose a virtual_helpers_context file, that we can parse > > > to figure out the appropriate labels to use for passt and friends? > > > > No, I don't think so. The helpers file is a bit of a special case > > that was needed because there were multiple contexts we needed to > > cope with for running QEMU. > > > > I don't see any reason not to follow what the kernel already does > > by relying on the labelled file context. > > Right, but wouldn't the idea of poking at the filesystem to retrieve > the label from the binary (passt_exec_t) and then applying a text > transformation to obtain the runtime label (passt_t) go directly > against the idea of not hardcoding information about a specific > policy implementation into libvirt? I'm not suggesting applying a text transformation. The example code using libselinux I described in the other reply actually askes the kernel to tell us what the target type will be when a process labelled passt_exec_t is execd. The answer we get back (passt_t) will come from the SELinux policy that is currently loaded in the kernel. This is doing exactly the same thing that would happen automatically if we had a normal exec() without the MCS stuff involved. > As I understand it, such a policy would allow virtqemud (virtd_t) to > execute passt (passt_exec_t) and automatically result in a transition > of the process to the desired context (passt_t). Yes, and I'm saying we must ask the kernel to tell us what that target context will be for the loaded policy, given the source file context. 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 :|
