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