[PATCH] apparmor: Add support for local profile customizations

[Jim Fehlig]

On 6/26/23 03:52, Andrea Bolognani wrote:
> On Fri, Jun 23, 2023 at 11:31:04AM -0600, Jim Fehlig wrote:
>> On 6/23/23 07:11, Andrea Bolognani wrote:
>>> However, not only you've added a few such statements in your recent
>>> commit 9b743ee19053, but I myself have done the same a couple months
>>> back with commit 7a39b04d683f, as part of enabling passt support. So
>>> in a way we've already started depending on AppArmor 3.0, in open
>>> contrast with our platform support policy.
>>>
>>> I'm quite unclear on the best way forward :(
>>
>> I'd prefer to defer support for local customizations of abstractions until
>> upstream libvirt can support apparmor >= 3.0. In the meantime commit
>> 9b743ee19053 can be changed to 'include <local/foo>' since we provide
>> local/foo. We'd need to drop the include entirely from your commit, and
>> again defer until upstream supports apparmor >= 3.0.
> 
> The problem is that passt support won't work if the abstraction is
> not included, and we can't make the include unconditional in that
> case. So we'd effectively have to wait two more years to make passt
> work with AppArmor, which I don't think is acceptable.
> 
> My best idea at the moment is to make a second copy of the AppArmor
> profiles targeting 2.x specifically, with a reduced feature set: no
> passt, no local overrides for abstractions. At build time, we can
> decide which version of the profiles to install based on the AppArmor
> version detected on the system.

Specifying which copy to use via a build time option is also an option :-).
Does your idea include preserving commit 9b743ee19053 and adjusting the 'include 
if exists' to 'include'?

> It wouldn't be pretty, but it would get us out of the current
> situation without modern distros having to sacrifice anything and
> without causing issues for older distros. In two years, we can drop
> the additional stuff and go back to a more sane state.
> 
> What do you think?

As you say, it's not pretty, but I don't have any better ideas. Perhaps 
Christian B. can give us some hints towards a nicer solution.

@cboltz: if needed there's a bit more context a few messages up the thread

https://listman.redhat.com/archives/libvir-list/2023-June/240424.html

Regards,
Jim