Re: [PATCH] apparmor: Add support for local profile customizations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux