On Thu, Jun 22, 2023 at 03:03:56PM -0600, Jim Fehlig wrote: > On 6/22/23 11:08, Jim Fehlig wrote: > > On 6/22/23 08:50, Andrea Bolognani wrote: > > > On Thu, Jun 08, 2023 at 10:37:43AM -0600, Jim Fehlig wrote: > > > > I assumed users would make VM customizations in the per-VM profiles. > > > > And I > > > > suppose overrides of abstractions seems a little odd to me, but that's > > > > subjective :-). I'm fine adding it if there's agreement. > > > > > > The per-VM profile is generated at runtime based on the template, no? > > > AFAIK there is no way for the admin to inject changes that affect a > > > single VM, but I could be wrong about this. > > > > The per-VM profile is only generated once, right? So in theory admins > > could amend existing per-VM profiles with custom config. > > While working on this I noticed there is no > /etc/apparmor.d/local/abstractions directory on SUSE-based distros. A lot of > packages put files in /etc/apparmor.d/local, but I couldn't find any adding > files to /etc/apparmor.d/local/abstractions. Nor could I find any apparmor > documentation regarding the use of that directory. Do you know if it's > common practice? Or is that Debian patch the only prior art?
In Debian, the directory and the files within it are created as part of the 'postinst' maintainer script. This makes some amount of sense, as having these files managed by the package manager would kinda defeat the purpose. Unfortunately, it also makes it way harder to figure out whether any packages in the archive besides libvirt are implementing this pattern :( I've come away empty-handed from my attempts, but I have also found a number of references[1] to libvirt's local abstractions overrides in other project's code and documentation, which IMO validates the idea that such a feature is indeed useful and should be available to all distros that use AppArmor, not just the Debian-based ones. That said, I've also found a comment in a somewhat recent Debian bug[2] that explains how support for this pattern comes out-of-the-box with AppArmor 3.0, with the caveat that it expects abstractions/foo.d/bar instead of local/abstractions/foo. Easy enough to adopt for upstream/SUSE, though Debian will have to consider how to carefully migrate things. The catch is that apparently the "include if exists" statement doesn't work well before 3.0, and our support matrix will include distros that are still on AppArmor 2.x for a couple more years :( 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 :( [1] https://github.com/search?q=%2Fetc%2Fapparmor.d%2Flocal%2Fabstractions%2F&type=code&p=2 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979500#10 -- Andrea Bolognani / Red Hat / Virtualization
