Re: [PATCH] apparmor: Upgrade ABI version to 4.0, explicitly enable user namespace creation

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 13 Jan 2026 05:06:41 -0800
Andrea Bolognani <abologna@redhat.com> wrote:

> On Mon, Jan 12, 2026 at 06:46:07PM +0100, Stefano Brivio wrote:
> > On Mon, 12 Jan 2026 08:11:44 -0700 Andrea Bolognani <abologna@redhat.com> wrote:
> >  
> > > [adding libvirt devel list]
> > >
> > > On Sat, Jan 10, 2026 at 04:14:30PM +0100, Stefano Brivio wrote:  
> > > > In the 3.0 AppArmor ABI version we currently use, user namespace rules
> > > > are not supported, and, as long as we load confined profiles, those
> > > > implicitly allow creation of user namespaces.
> > > >
> > > > However, ABI version 4.0 introduces rules for user namespaces, and if
> > > > we don't specify any, we can't create user namespaces, see:
> > > >
> > > >   https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction
> > > >
> > > > This wouldn't affect us in general, given that we're using the 3.0
> > > > ABI, but libvirt's policy uses 4.0 instead, and if our abstractions
> > > > are used from there, no matter what ABI policy version we declare,
> > > > rules for user namespace creation now match ABI policy version 4.0.  
> > >
> > > AFAICT libvirt's policy doesn't explicitly declares any ABI version,
> > > so how does that work? Is the most recent one being used in that
> > > case?  
> >
> > Oh, right, I forgot to mention that this is implicit from including
> > abstraction/base in libvirt's policy, which uses 4.0 on all the current
> > versions of AppArmor-enabled distributions I checked (Debian, including
> > stable/trixie, Ubuntu, openSUSE).  
> 
> Got it.
> 
> Note that libvirt still targets Debian 12 too, and that's stuck with
> AppArmor 3. Same for Ubuntu 22.04, though that one is getting dropped
> from our support matrix in just a few months.

Ah, thanks for the information. But anyway I don't plan to backport this
change to anything before trixie, so I don't think there should be any
problem with it.

> > > Do we want to make the ABI version explicit in libvirt's policy? If
> > > so, should we stick with 3.0 for maximum compatibility?  
> >
> > I wouldn't make it explicit. Yes, sticking to 3.0 would have avoided
> > this issue and resulted in better compatibility overall but would cause
> > even more problems if you ever need to switch "back" to 4.0 at some
> > point in time.
> >
> > I think that using the version from abstraction/base as libvirt does
> > is actually a more convenient and compatible approach in general.
> >
> > We didn't do that in passt's policy because the rules included there
> > are too broad, but given that libvirtd's policy already includes it,
> > I'd suggest to keep it that way.  
> 
> That sounds good, especially given the OS support constraints
> mentioned above.
> 
> Nothing to be done on the libvirt side then! That's perfect :)

Cheers. :)

-- 
Stefano