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.
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?
--
Andrea Bolognani / Red Hat / Virtualization