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