[PATCH] apparmor: Add support for local profile customizations

[Andrea Bolognani]

On Mon, Jun 26, 2023 at 09:42:32AM -0600, Jim Fehlig wrote:
> 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'?

The modern (3.x) version would install the profile as it is
currently, while the legacy (2.x) version would have the "include if
exists" replaced with "include".

We could also decide to leave the include out altogether for the
legacy version, and simply keep it as the less-featureful version it
has been until now. In fact, I wonder if we should install
placeholder files for the profiles at all?

For abstractions on 3.x, the abstractions/foo.d approach means that
such placeholders do not exist. On the other hand, you could argue
that the empty abstractions/foo.d directory and the empty local/foo
file both serve the same purpose of providing a hint for the user
that they can customize things using that mechanism...

FWIW, Debian seems to consistently create placeholders for profiles.
I think this is done automatically by the dh-apparmor utility that's
used as standard for packaging. But that feels like a decision better
left to each downstream... Maybe we should look into what upstream
AppArmor does for its own profiles and abstractions.

-- 
Andrea Bolognani / Red Hat / Virtualization