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

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

[Stefano Brivio]

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.

As a result, when libvirtd runs as root, and its profile includes
passt's abstraction, cf. commit 66769c2de825 ("apparmor: Workaround
for unconfined libvirtd when triggered by unprivileged user"), passt
can't detach user namespaces and will fail to start, as reported by
Niklas:

  ERROR    internal error: Child process (passt --one-off --socket /run/libvirt/qemu/passt/1-haos-net0.socket --pid /run/libvirt/qemu/passt/1-haos-net0-passt.pid --tcp-ports 8123) unexpected exit status 1: Multiple interfaces with IPv6 routes, picked first
  UNIX domain socket bound at /run/libvirt/qemu/passt/1-haos-net0.socket
  Couldn't create user namespace: Permission denied

This isn't a problem with libvirtd running as regular user, because
in that case, as a workaround, passt currently runs under its own
profile, not as a libvirtd subprofile (see commit referenced above).

Given that ABI 4.0 has been around for a while, being introduced in
July 2023, finally take the step to upgrade to it and explicitly
enable user namespace creation.

No further changes are needed in the existing policies to match new
features introduced in AppArmor 4.0.

Reported-by: Niklas Edmundsson <nikke@accum.se>
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124801
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
---
 contrib/apparmor/abstractions/passt   | 3 ++-
 contrib/apparmor/abstractions/pasta   | 2 +-
 contrib/apparmor/usr.bin.passt        | 2 +-
 contrib/apparmor/usr.bin.passt-repair | 2 +-
 contrib/apparmor/usr.bin.pasta        | 2 +-
 5 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/contrib/apparmor/abstractions/passt b/contrib/apparmor/abstractions/passt
index 25b2ea8..0ffadaf 100644
--- a/contrib/apparmor/abstractions/passt
+++ b/contrib/apparmor/abstractions/passt
@@ -11,7 +11,7 @@
 # Copyright (c) 2022 Red Hat GmbH
 # Author: Stefano Brivio <sbrivio@redhat.com>
 
-  abi <abi/3.0>,
+  abi <abi/4.0>,
 
   include <abstractions/base>
 
@@ -24,6 +24,7 @@
   capability setpcap,
   capability net_admin,
   capability sys_ptrace,
+  userns,
 
   /					r,	# isolate_prefork(), isolation.c
   mount options=(rw, runbindable) -> /,
diff --git a/contrib/apparmor/abstractions/pasta b/contrib/apparmor/abstractions/pasta
index 9f73bee..251d4a2 100644
--- a/contrib/apparmor/abstractions/pasta
+++ b/contrib/apparmor/abstractions/pasta
@@ -11,7 +11,7 @@
 # Copyright (c) 2022 Red Hat GmbH
 # Author: Stefano Brivio <sbrivio@redhat.com>
 
-  abi <abi/3.0>,
+  abi <abi/4.0>,
 
   include <abstractions/passt>
 
diff --git a/contrib/apparmor/usr.bin.passt b/contrib/apparmor/usr.bin.passt
index 62a4514..c123a86 100644
--- a/contrib/apparmor/usr.bin.passt
+++ b/contrib/apparmor/usr.bin.passt
@@ -11,7 +11,7 @@
 # Copyright (c) 2022 Red Hat GmbH
 # Author: Stefano Brivio <sbrivio@redhat.com>
 
-abi <abi/3.0>,
+abi <abi/4.0>,
 
 include <tunables/global>
 
diff --git a/contrib/apparmor/usr.bin.passt-repair b/contrib/apparmor/usr.bin.passt-repair
index 901189d..23ff1ce 100644
--- a/contrib/apparmor/usr.bin.passt-repair
+++ b/contrib/apparmor/usr.bin.passt-repair
@@ -11,7 +11,7 @@
 # Copyright (c) 2025 Red Hat GmbH
 # Author: Stefano Brivio <sbrivio@redhat.com>
 
-abi <abi/3.0>,
+abi <abi/4.0>,
 
 #include <tunables/global>
 
diff --git a/contrib/apparmor/usr.bin.pasta b/contrib/apparmor/usr.bin.pasta
index 2483968..56b5024 100644
--- a/contrib/apparmor/usr.bin.pasta
+++ b/contrib/apparmor/usr.bin.pasta
@@ -11,7 +11,7 @@
 # Copyright (c) 2022 Red Hat GmbH
 # Author: Stefano Brivio <sbrivio@redhat.com>
 
-abi <abi/3.0>,
+abi <abi/4.0>,
 
 include <tunables/global>
 
-- 
2.43.0

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

[Andrea Bolognani]

[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?

Assuming that's the case, how far back will that result in ABI 4.0
being the effective one? It looks like Debian only got AppArmor 4+ in
March of last year.

Do we want to make the ABI version explicit in libvirt's policy? If
so, should we stick with 3.0 for maximum compatibility?

> As a result, when libvirtd runs as root, and its profile includes
> passt's abstraction, cf. commit 66769c2de825 ("apparmor: Workaround
> for unconfined libvirtd when triggered by unprivileged user"), passt
> can't detach user namespaces and will fail to start, as reported by
> Niklas:
>
>   ERROR    internal error: Child process (passt --one-off --socket /run/libvirt/qemu/passt/1-haos-net0.socket --pid /run/libvirt/qemu/passt/1-haos-net0-passt.pid --tcp-ports 8123) unexpected exit status 1: Multiple interfaces with IPv6 routes, picked first
>   UNIX domain socket bound at /run/libvirt/qemu/passt/1-haos-net0.socket
>   Couldn't create user namespace: Permission denied
>
> This isn't a problem with libvirtd running as regular user, because
> in that case, as a workaround, passt currently runs under its own
> profile, not as a libvirtd subprofile (see commit referenced above).
>
> Given that ABI 4.0 has been around for a while, being introduced in
> July 2023, finally take the step to upgrade to it and explicitly
> enable user namespace creation.
>
> No further changes are needed in the existing policies to match new
> features introduced in AppArmor 4.0.
>
> Reported-by: Niklas Edmundsson <nikke@accum.se>
> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124801
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> ---
>  contrib/apparmor/abstractions/passt   | 3 ++-
>  contrib/apparmor/abstractions/pasta   | 2 +-
>  contrib/apparmor/usr.bin.passt        | 2 +-
>  contrib/apparmor/usr.bin.passt-repair | 2 +-
>  contrib/apparmor/usr.bin.pasta        | 2 +-
>  5 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/contrib/apparmor/abstractions/passt b/contrib/apparmor/abstractions/passt
> index 25b2ea8..0ffadaf 100644
> --- a/contrib/apparmor/abstractions/passt
> +++ b/contrib/apparmor/abstractions/passt
> @@ -11,7 +11,7 @@
>  # Copyright (c) 2022 Red Hat GmbH
>  # Author: Stefano Brivio <sbrivio@redhat.com>
>
> -  abi <abi/3.0>,
> +  abi <abi/4.0>,
>
>    include <abstractions/base>
>
> @@ -24,6 +24,7 @@
>    capability setpcap,
>    capability net_admin,
>    capability sys_ptrace,
> +  userns,
>
>    /					r,	# isolate_prefork(), isolation.c
>    mount options=(rw, runbindable) -> /,
> diff --git a/contrib/apparmor/abstractions/pasta b/contrib/apparmor/abstractions/pasta
> index 9f73bee..251d4a2 100644
> --- a/contrib/apparmor/abstractions/pasta
> +++ b/contrib/apparmor/abstractions/pasta
> @@ -11,7 +11,7 @@
>  # Copyright (c) 2022 Red Hat GmbH
>  # Author: Stefano Brivio <sbrivio@redhat.com>
>
> -  abi <abi/3.0>,
> +  abi <abi/4.0>,
>
>    include <abstractions/passt>
>
> diff --git a/contrib/apparmor/usr.bin.passt b/contrib/apparmor/usr.bin.passt
> index 62a4514..c123a86 100644
> --- a/contrib/apparmor/usr.bin.passt
> +++ b/contrib/apparmor/usr.bin.passt
> @@ -11,7 +11,7 @@
>  # Copyright (c) 2022 Red Hat GmbH
>  # Author: Stefano Brivio <sbrivio@redhat.com>
>
> -abi <abi/3.0>,
> +abi <abi/4.0>,
>
>  include <tunables/global>
>
> diff --git a/contrib/apparmor/usr.bin.passt-repair b/contrib/apparmor/usr.bin.passt-repair
> index 901189d..23ff1ce 100644
> --- a/contrib/apparmor/usr.bin.passt-repair
> +++ b/contrib/apparmor/usr.bin.passt-repair
> @@ -11,7 +11,7 @@
>  # Copyright (c) 2025 Red Hat GmbH
>  # Author: Stefano Brivio <sbrivio@redhat.com>
>
> -abi <abi/3.0>,
> +abi <abi/4.0>,
>
>  #include <tunables/global>
>
> diff --git a/contrib/apparmor/usr.bin.pasta b/contrib/apparmor/usr.bin.pasta
> index 2483968..56b5024 100644
> --- a/contrib/apparmor/usr.bin.pasta
> +++ b/contrib/apparmor/usr.bin.pasta
> @@ -11,7 +11,7 @@
>  # Copyright (c) 2022 Red Hat GmbH
>  # Author: Stefano Brivio <sbrivio@redhat.com>
>
> -abi <abi/3.0>,
> +abi <abi/4.0>,
>
>  include <tunables/global>
>
> --
> 2.43.0
>

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

[Stefano Brivio]

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).

> Assuming that's the case, how far back will that result in ABI 4.0
> being the effective one? It looks like Debian only got AppArmor 4+ in
> March of last year.

Given that it's bound to the version from abstraction/base, the only
risk I see is that passt might now ship a policy with an ABI version
that's too new for the distribution at hand.

But ABI 4.0 has been around for more than two years now, so I don't
really see a problem.

> 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.

> > As a result, when libvirtd runs as root, and its profile includes
> > passt's abstraction, cf. commit 66769c2de825 ("apparmor: Workaround
> > for unconfined libvirtd when triggered by unprivileged user"), passt
> > can't detach user namespaces and will fail to start, as reported by
> > Niklas:
> >
> >   ERROR    internal error: Child process (passt --one-off --socket /run/libvirt/qemu/passt/1-haos-net0.socket --pid /run/libvirt/qemu/passt/1-haos-net0-passt.pid --tcp-ports 8123) unexpected exit status 1: Multiple interfaces with IPv6 routes, picked first
> >   UNIX domain socket bound at /run/libvirt/qemu/passt/1-haos-net0.socket
> >   Couldn't create user namespace: Permission denied
> >
> > This isn't a problem with libvirtd running as regular user, because
> > in that case, as a workaround, passt currently runs under its own
> > profile, not as a libvirtd subprofile (see commit referenced above).
> >
> > Given that ABI 4.0 has been around for a while, being introduced in
> > July 2023, finally take the step to upgrade to it and explicitly
> > enable user namespace creation.
> >
> > No further changes are needed in the existing policies to match new
> > features introduced in AppArmor 4.0.
> >
> > Reported-by: Niklas Edmundsson <nikke@accum.se>
> > Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124801
> > Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> > ---
> >  contrib/apparmor/abstractions/passt   | 3 ++-
> >  contrib/apparmor/abstractions/pasta   | 2 +-
> >  contrib/apparmor/usr.bin.passt        | 2 +-
> >  contrib/apparmor/usr.bin.passt-repair | 2 +-
> >  contrib/apparmor/usr.bin.pasta        | 2 +-
> >  5 files changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/contrib/apparmor/abstractions/passt b/contrib/apparmor/abstractions/passt
> > index 25b2ea8..0ffadaf 100644
> > --- a/contrib/apparmor/abstractions/passt
> > +++ b/contrib/apparmor/abstractions/passt
> > @@ -11,7 +11,7 @@
> >  # Copyright (c) 2022 Red Hat GmbH
> >  # Author: Stefano Brivio <sbrivio@redhat.com>
> >
> > -  abi <abi/3.0>,
> > +  abi <abi/4.0>,
> >
> >    include <abstractions/base>
> >
> > @@ -24,6 +24,7 @@
> >    capability setpcap,
> >    capability net_admin,
> >    capability sys_ptrace,
> > +  userns,
> >
> >    /					r,	# isolate_prefork(), isolation.c
> >    mount options=(rw, runbindable) -> /,
> > diff --git a/contrib/apparmor/abstractions/pasta b/contrib/apparmor/abstractions/pasta
> > index 9f73bee..251d4a2 100644
> > --- a/contrib/apparmor/abstractions/pasta
> > +++ b/contrib/apparmor/abstractions/pasta
> > @@ -11,7 +11,7 @@
> >  # Copyright (c) 2022 Red Hat GmbH
> >  # Author: Stefano Brivio <sbrivio@redhat.com>
> >
> > -  abi <abi/3.0>,
> > +  abi <abi/4.0>,
> >
> >    include <abstractions/passt>
> >
> > diff --git a/contrib/apparmor/usr.bin.passt b/contrib/apparmor/usr.bin.passt
> > index 62a4514..c123a86 100644
> > --- a/contrib/apparmor/usr.bin.passt
> > +++ b/contrib/apparmor/usr.bin.passt
> > @@ -11,7 +11,7 @@
> >  # Copyright (c) 2022 Red Hat GmbH
> >  # Author: Stefano Brivio <sbrivio@redhat.com>
> >
> > -abi <abi/3.0>,
> > +abi <abi/4.0>,
> >
> >  include <tunables/global>
> >
> > diff --git a/contrib/apparmor/usr.bin.passt-repair b/contrib/apparmor/usr.bin.passt-repair
> > index 901189d..23ff1ce 100644
> > --- a/contrib/apparmor/usr.bin.passt-repair
> > +++ b/contrib/apparmor/usr.bin.passt-repair
> > @@ -11,7 +11,7 @@
> >  # Copyright (c) 2025 Red Hat GmbH
> >  # Author: Stefano Brivio <sbrivio@redhat.com>
> >
> > -abi <abi/3.0>,
> > +abi <abi/4.0>,
> >
> >  #include <tunables/global>
> >
> > diff --git a/contrib/apparmor/usr.bin.pasta b/contrib/apparmor/usr.bin.pasta
> > index 2483968..56b5024 100644
> > --- a/contrib/apparmor/usr.bin.pasta
> > +++ b/contrib/apparmor/usr.bin.pasta
> > @@ -11,7 +11,7 @@
> >  # Copyright (c) 2022 Red Hat GmbH
> >  # Author: Stefano Brivio <sbrivio@redhat.com>
> >
> > -abi <abi/3.0>,
> > +abi <abi/4.0>,
> >
> >  include <tunables/global>
> >
> > --
> > 2.43.0

-- 
Stefano

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

[Andrea Bolognani]

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.

> > 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 :)

-- 
Andrea Bolognani / Red Hat / Virtualization