[apparmor] Need assistance with DENIED userns_create for non-root podman inside an Incus container

[John Johansen]

On 1/25/26 06:23, Kees Bakker wrote:
> Op 25-01-2026 om 04:44 schreef John Johansen:
>> On 1/24/26 07:37, Kees Bakker wrote:
>>> Hi,
>>>
>>> My setup is a Ubuntu24 with an Incus server (6.20).
>>> One Incus container runs Fedora 43 where I want to run non-root podman.
>>>
>>> Inside the container
>>>
>>> [root at f43 ~]# sudo -u fedora -i
>>> [fedora at f43 ~]$ podman run -t -i hello-world
>>> cannot clone: Permission denied
>>> Error: cannot re-exec process
>>>
>>> On the Ubuntu24 host I see this in journalctl
>>>
>>> jan 24 16:33:41 rapper kernel: audit: type=1400 audit(1769268821.264:1554): apparmor="DENIED" operation="userns_create" class="namespace" info="Userns create restricted - failed to find unprivileged_userns profile" error=-13 namespace="root//incus-f43_<var-lib-incus>" profile="unconfined" pid=2332667 comm="podman" requested="userns_create" denied="userns_create" target="unprivileged_userns"
>>>
>>> My question, what do I have to do on the Ubuntu24 server to allow running non-root podman?
>>> Any help or suggestion is greatly appreciated.
>>
>> you are encountering the unprivileged user namespace restriction(1-5).
>>
>> You either need to confine the container, giving access to user namespaces, or you need to disable the restriction.
>>
>> to temporarily disable you can do
>>
>>   sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
>>
>> to permanently disable
>>
>>   sudo bash -c "echo kernel.apparmor_restrict_unprivileged_userns=0 > /etc/sysctl.d/60-apparmor-namespace.conf"
>>
>>
>>
>> 1. https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction
>> 2. https://discourse.ubuntu.com/t/understanding-apparmor-user-namespace-restriction/58007
>> 3. https://discourse.ubuntu.com/t/plucky-puffin-release-notes/48687
>> 4. https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces
>> 5. https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626 
> 
> 
> A few months ago there was a discussion [1] about an identical problem. Two suggested solutions were:
> 
> # Manually create the unprivileged_userns profile, by using AppArmor on the host. Something like
> |sudo apparmor_parser -n 'incus-mycontainer_<var-lib-incus>' -r /etc/apparmor.d/unprivileged_userns|
> # Use your own AppArmor profile, with |raw.apparmor = profile|
> 
> So far I don't quite understand how to do either of the two.> Perhaps the above apparmor_parser isn't quite correct.
> 

the unprivileged_userns profile is special in that if present it is
the default profile that unconfined will transition to when it tries
to create a userns. The unprivileged_userns profile provided by
upstream and ubuntu grants broad privileges (like unconfined) but
strips capabilities from the container.

This allows user namespaces to be created, but not have privilege
within the container which is not what incus/lxd want. Adding the
ability to have capabilities in the container is a half step to
disabling the unprivileged user namespace restriction.  In that it
allows any unprivileged unconfined host application to create a user
namespace and have privilege within the user namespace.

Depending on how the container is setup, the unprivileged user
namespace restriction may still apply to unprivileged applications in
the container.

Generally speaking I wouldn't recommend modifying the
unprivileged_userns profile.  As that will group your containers in
with other applications, that would use that profile. Which can result
in ipc restrictions, and can also lead to issues with passing files
from the host to the container.

You are better off either

1. making an unconfined profile for your container, for selectively
    disability the restriction on your container. This profile can
    potentially be used to by-pass the restriction by other applications,
    see the Qualys three by-passes reference, but it is local so an
    attacker would have to know to look for it.

    profile mycontainer flags=(unconfined) {
       # required to allow unconfined to create userns's without
       # being subject to the restriction
       allow userns,
    }

2. disable the unprivileged user namespace restriction, as
    mentioned previously.


You could of course, confine the container with a full profile, but
that is going to be more work, and not something I recommend unless
you are more familiar with apparmor, and profiling.

The advantage of using an unconfined profile, or disabling the
restriction is that unconfined atm is the only part of apparmor
currently allowed to do object (fd) delegation which makes dealing
with things like containers a lot easier. This ability will come to
regular profiles, but getting all the pieces ready is still a wip.


> Also, when I create an Incus container with Ubuntu24 AND if I then install apparmor I can
> run rootless podman.
> 

right. Unprivileged user namespaces are kind of a double edged
sword. The are useful and can increase security when used correctly,
but they also open some kernel interfaces to unprivileged users, and
that has been used as the base for many root exploits. To be clear the
bugs exploited, aren't usually in unprivileged namespaces per say but
in other kernel subsystems that unprivileged user namespaces make
available.

You can use rootless podman, in an Incus container, or straight on the
host. With the restriction enabled you need to confine podman with a
profile that allows it to user the unprivileged user namespace. This
tells AppArmor that this is a known good application and to trust it.

> On the host, in the output of "aa-status --filter.mode=unconfined" there is
> 
>     :incus-dawarich_<var-lib-incus>:podman
>     :incus-forgejo-runner_<var-lib-incus>:podman
> 
> BTW In apparmor documentation I couldn't find what the meaning of the ":" is.
> 

it identifies an apparmor policy namespace. The name between the two
colon's is the namespace name. In this case its helps identify that it
has been setup by incus. Its possible it could be a random unique
identifier, but it really helps when who ever setups a namespace gives
it a name that helps identify it.

So in breaking down the above,

policy namespace = incus-forgejo-runner_<var-lib-incus
profile in the policy namespace = podman

The policy namespace allows the container to have its own set of
profiles that don't interact/interfere with the hosts profiles.

If you use aa-status within the container, you will find that it only
reports (ie. does not include the namespace)

   podman

this is because the container can not see the hosts policy or that it
is in a policy namespace.

> The thing is, I want Fedora43 in the Incus container to run podman.
> Fedora has no apparmor.
> 

right, it doesn't need to have apparmor, but you could install
apparmor if you really want.

How it will work is Fedora in the container will use the Ubuntu kernel
and boot with selinux disabled. As long as the unprivileged user
namespace restriction is disabled, there won't be any apparmor policy
loaded in the container, so podman should run as unconfined. While
Fedora in the container doesn't have aa-status, you can use ps -Z to
check this.

The caveat here is that the restriction needs to be disabled, you
can't just confine the container. The reason for this is atm the
restriction is globally enabled/disabled for unconfined (being able to
toggle it per ns is coming).  When applications are placed into a
policy namespace they will use the profiles in that namespace
including, a policy namespace specific version of unconfined.

This means unconfined applications within the container will have the
restriction applied unless, the host has disabled it.  There is a
caveat here, around apparmor confinement on the container.  Currently
the unprivileged user namespace restriction is not being performed

But if you disable the restriction on the host rootless podman in the
Fedora container should just work.




> [1] https://discuss.linuxcontainers.org/t/error-with-rootless-podman/24250/9
>