Re: [libvirt PATCH] apparmor: Enable passt support
On Tue, Mar 07, 2023 at 01:28:41PM -0800, Andrea Bolognani wrote:
On Tue, Mar 07, 2023 at 07:04:25PM +0000, Daniel P. Berrangé wrote:
> On Tue, Mar 07, 2023 at 08:02:37PM +0100, Andrea Bolognani wrote:
> > + # support for passt network back-end
> > + /usr/bin/passt Cx -> passt,
> > +
> > + profile passt {
> > + /usr/bin/passt r,
> > +
> > + signal (receive) set=("term") peer=/usr/sbin/libvirtd,
> > + signal (receive) set=("term") peer=libvirtd,
>
> What's the rationale for having both qualified & unqualified
> here, but not below ?
Cargo cult. That's what the top-level profile does, so I figured it
would be good enough for the subprofile too.
I've seen stuff like peer=(label=libvirtd) as well, but I haven't
investigated the various notations and how exactly they differ.
It looks like using the label= version is only needed when additional
information is passed, for example in
unix (send, receive) type=stream addr=none peer=(label=unconfined addr=none),
Each profile has its own name attached as a label, so
peer=libvirtd
and
peer=(label=libvirtd)
are effectively equivalent. Similarly, the binary running under a
profile also becomes a label, making
peer=libvirtd
and
peer=/usr/sbin/libvirtd
also equivalent, which means that having both in the profile is
redundant.
There's plenty of room for improvement in the AppArmor profile
in
general, but that's a task for another day :)
Based on the above, I'm working on a patch that cleans up the
situation by sticking with the simpler form. Plus some other stuff.
I don't want to make such a cleanup patch a requirement for this
functionally relevant one though, especially in the not entirely
remote chance that I have completely misunderstood how this stuff
work O:-)
So I'd prefer to keep the cargo cult line for now, and clean
everything up at once later.
--
Andrea Bolognani / Red Hat / Virtualization