On Tue, 12 Nov 2024 13:52:43 +0000
"Richard W.M. Jones" <rjo...@redhat.com> wrote:
> On Tue, Nov 12, 2024 at 02:22:19PM +0100, Stefano Brivio wrote:
> > On Tue, 12 Nov 2024 13:08:00 +0000
> > "Richard W.M. Jones" <rjo...@redhat.com> wrote:
> >
> > > Do you know where the apparmor profile is shipped right now? Could it
> > > be in libvirt (src/security/apparmor)?
> >
> > Yes, but that's the one for libvirt components themselves, and used on
> > Debian without changes from upstream. I don't think that that AppArmor
> > profile should cover libguestfs as well, correct?
>
> I'm not sure. Probably the answer is whatever the thing is that now
> allows libguestfs to launch qemu directly, should also allow
> libguestfs to launch passt directly.
The thing that allows libguestfs to launch QEMU directly is the lack of
an AppArmor profile for QEMU, which therefore runs as non-profiled
(unrestricted).
Given that passt ships its own abstraction, we need to add a profile
for libguestfs, including the abstraction for passt, which tells
AppArmor where passt can write its socket and PID file, if started by
libguestfs. There's a similar mechanism in SELinux, based on
interfaces.
Breaking down the passt "subprofile" example I shared earlier on this
ticket:
> profile passt {
This should be part of the new profile for, say, virt-sysprep. The
subprofile allows passt to:
> /usr/bin/passt r,
- read /usr/bin/passt
> signal (receive) set=("term") peer=/usr/bin/virt-sysprep,
> signal (receive) set=("term") peer=virt-sysprep,
- receive SIGTERM from virt-sysprep
> # for launch_passt(), lib/launch-direct.c
> # and similar rules for /usr/bin/virt-*
>
> owner @{run}/user/[0-9]*/libguestfs*/* rw,
> owner @{run}/libguestfs*/* rw,
- read and write files (socket and PID file) there
> include if exists <abstractions/passt>
- plus everything that the passt abstraction allows
> }
> > Note that, as far as I know, this issue only happens with libguestfs
> > using "direct" mode (even though it's not explicitly set anywhere, so
> > I'm not sure I got this right).
>
> Direct mode (run qemu directly) is the upstream default, and also used
> by Debian. But it's not what we use in Fedora. In Fedora we use the
> libvirt mode (run qemu via libvirt).
Ah, thanks for solving the mystery.
> This affects passt because in libvirt mode (on Fedora) the session
> libvirtd will run passt.
>
> So you should expect that Debian & Fedora behave differently, as well
> as the AppArmour vs SELinux difference.
>
> > > We don't ship any SELinux or apparmor profiles upstream in libguestfs
> > > or the tools, so assigning the bug upstream to us won't result in any
> > > useful outcome.
> >
> > Right... I noticed as I wanted to submit an upstream patch for
> > libguestfs to fix this and I realised that there are no AppArmor
> > profiles there.
> >
> > By "reassigning to guestfs-tools or libguestfs" I actually meant the
> > downstream packages.
>
> .. in Debian.
Right.
> A similar bug was assigned to selinux-policy in RHEL:
>
> https://issues.redhat.com/browse/RHEL-65502
That's not a public link, but anyway, yes, on Fedora and RHEL things
work differently because libvirt doesn't ship its own profile there, so
the rules come from the "core" SELinux policy.
On Debian, there's no such thing, and libvirt ships its own bit.
Here, I think we finally have to add AppArmor profiles for
guestfs-tools (or libguestfs). I can help with that if desired. I would
suggest to start with something very loose where the tools can write
and read pretty much everywhere.
If it's too complicated, as a short term solution, we could ship those
as part of the libvirt package or as part of passt.
--
Stefano
