On Tue, Jun 28, 2022 at 4:14 PM Martin Kletzander
<mkletzan(a)redhat.com> wrote:
> On Tue, Jun 28, 2022 at 10:18:25AM -0400, David Michael wrote:
> >On Tue, Jun 28, 2022 at 10:03 AM Daniel P. Berrangé <berrange(a)redhat.com>
wrote:
> >> On Tue, Jun 28, 2022 at 08:33:41AM -0400, David Michael wrote:
> >> > This supports sockets created by libvirt and passed by FD using the
> >> > same method as in security_dac.c.
> >> >
> >> > Signed-off-by: David Michael <david(a)bigbadwolfsecurity.com>
> >> > ---
> >> >
> >> > Hi,
> >> >
> >> > Custom SELinux labels are not applied to sockets when they have
> >> > mode="bind", but other security models (DAC) allow changing
these
> >> > sockets. Can the same method be used to support SELinux?
> >>
> >> This is rather intriguing. There must have been some compelling
> >> reason why we intentionally skipped listener sockets for SELinux
> >> labelling originally, but I'm struggling to recall what it could
> >> have been. Conceptually it makes sense to want to label the
> >> listener sockets with the per-VM label.
> >>
>
> Could it be that we only thought about the scenario of someone
> connecting to the socket (and the fact that it matters more what the
> actual socket label is rather than its file representation) but did not
> think about other possibilities, e.g. QEMU rewriting the socket (because
> we remove it before starting or any other reason) or some custom policy?
I checked the Git history for when DAC made the change, which has some
further links for context:
https://gitlab.com/libvirt/libvirt/-/commit/d6b8838dd83697f721fe0706068df...
It looks like socket DAC relabeling was added shortly after libvirt
started creating the sockets to pass as FDs within the last few years,
but the related SELinux socket code hasn't been modified since it was
added a decade ago. Seems like it just got left behind after that
change?
Yeah that looks like the cause. Originally when QEMU invoked the
bind() + listen(), it would inherit labelling, so we wouldn't need
todo anything special ourselves. When we switched to creating it
ourselves & passing the FD we broke that implicit behaviour we
relied on.
With regards,
Daniel
--
|: