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?
Looking at the SELinux policy for Fedora, the virt module contains a
bunch of instances where an external policy is imported in order to
give virtqemud the ability to run external commands. For example, for
dnsmasq we have
optional_policy(`
dnsmasq_domtrans(virtd_t)
dnsmasq_signal(virtd_t)
dnsmasq_kill(virtd_t)
dnsmasq_signull(virtd_t)
dnsmasq_create_pid_dirs(virtd_t)
dnsmasq_filetrans_named_content_fromdir(virtd_t, virt_var_run_t);
dnsmasq_manage_pid_files(virtd_t)
')
This looks pretty similar to what Stefano has proposed doing for
passt in [1]:
optional_policy(`
passt_socket(virt_domain)
')
optional_policy(`
passt_domtrans(virtd_t)
passt_kill(virtd_t)
')
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).
Why would this approach not be okay?
[1] https://github.com/fedora-selinux/selinux-policy/pull/1613
--
Andrea Bolognani / Red Hat / Virtualization
