unconfined profile denies userns_create for chromium based processes

[Timo Witte]

For Ubuntu 22.10, since the last kernel update, i can´t launch any chromium based browser, due to apparmor denying userns_create

dmesg shows:
apparmor="DENIED" operation="userns_create" class="namespace" info="User namespace creation restricted" error=-13 profile="unconfined" pid=21323 comm="steamwebhelper" requested="userns_create" denied="userns_create"

This happens for every process which uses a chromium engine, like google chrome itself or in this case steamwebhelper.

Might be related to this change?: https://patchwork.<email address hidden>/

not sure if it got merged in this form though..

[Alex Murray (alexmurray)]

This sounds like a kernel regression.

The commit you link to is for SELinux, which is not enabled by default in Ubuntu, so I doubt it is that specifically - instead I suspect this is due to the following commit: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/kinetic/commit/?h=master-next&id=30bce26855c9171f8dee74d93308fd506730c914

The logic here:

int aa_profile_ns_perm(struct aa_profile *profile, struct common_audit_data *sa,
                      u32 request)
{
...
       if (profile_unconfined(profile)) {
               if (!unprivileged_userns_restricted ||
                   ns_capable_noaudit(current_user_ns(), CAP_SYS_ADMIN))
                   return 0;

               aad(sa)->info = "User namespace creation restricted";
               /* fall through to below allows complain mode to override */
       } else {
               struct aa_ruleset *rules = list_first_entry(&profile->rules,
                                                           typeof(*rules),
                                                           list);
               aa_state_t state;

               state = RULE_MEDIATES(rules, aad(sa)->class);
               if (!state)
                       /* TODO: add flag to complain about unmediated */
                       return 0;
               perms = *aa_lookup_perms(&rules->policy, state);
       }

       aa_apply_modes_to_perms(profile, &perms);
       return aa_check_perms(profile, &perms, request, sa, audit_ns_cb);
}

Seems to indicate that all unconfined processes that do not have CAP_SYS_ADMIN will be denied the ability to use user namespaces - this feels like a definite regression / policy change within the kernel itself.

Should the kernel instead be built with CONFIG_SECURITY_APPARMOR_RESTRICT_USERNS=n ?

Or is this code not doing what it was intended to do.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1990064

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[John Johansen (jjohansen)]

Not a regression, or at least an intended regression (ie. it is doing exactly what is intended). This is exactly what has been talked about for 6+ months. unprivileged user_namespaces are going away, but instead of the big system level sysctl we can allow them on a per application basis.

The only question is whether we default this off for 22.10

With the current kernel there are two options for dealing with this

1. for applications that don't have CAP_SYS_ADMIN confine the application if it needs to use user namespaces

2. set the sysctl apparmor_restrict_unprivileged_userns to 0

Its possible we could set this option in the kernel to default N. But it HAS to change soon. unprivileged usernamespaces have been used as part of the exploit chain in multiple attacks over the last several years. Debian defaults them off with the sysctl, and this gives them a potential option to move forward.

I will re-iterate, unprivieged user_namespaces are going away, this is a requirement.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[James Lewis (james-fsck)]

It broke for me between 5.19.0-15 and 5.19.0-17, and breaks every flatpak app I have installed.

[James Lewis (james-fsck)]

NB, also broke Steam (from .deb).

Is there a link anywhere to some of this discussion, happy for security to be improved, but I'd like to understand what is being disabled, and what the specific issue is.

[John Johansen (jjohansen)]

In short unprivileged user namespaces a vector for exploit chains, as they expose interfaces that otherwise would not be available.

4 out 5 exploits chains in pwn2own 2022 used unprivileged user namespaces. They were also used in 2021, 2020, ... Yes the actual vulnerabilities were in other interface io_uring, ebpf, nftables, ... but none of them would have been available without unprivileged user namespaces.

Previously we only had the option of using a system wide sysctl kernel.unprivileged_userns_clone to disable unprivileged user namespaces. Debian defaults this to off, and you have to opt in.

Ubuntu is now moving towards a more fine grained approach where they can be selectively turned on for some applications but aren't generally available.

For 22.10 the apparmor sysctl will be defaulted to off, while further packaging work is done for applications that need access to unprivileged user namespaces.

[intrigeri (intrigeri)]

> Previously we only had the option of using a system wide sysctl
> kernel.unprivileged_userns_clone to disable unprivileged user
> namespaces. Debian defaults this to off, and you have to opt in.

Just to avoid misunderstandings (I failed to parse the above sentence
unambiguously): in Debian, unprivileged user namespaces have been
enabled by default since Bullseye.

[James Lewis (james-fsck)]

I'm still trying to understand the exact implications of this, since I make extensive use of LXC containers, using subuid/subgid mapping, so that users can create containers without needing access to UID 0.

Are we talking about blocking namespaces where UID 0 in the container is mapped to the real UID 0, or will it also impact containers where UID 0 in the container is mapped to some other UID.

[John Johansen (jjohansen)]

It will affect both. The exact effect will depend on how things are set up. Unconfined privileged processes will still have access to create user namespaces as they see fit. The processes within the user namespace will be subject to similar restrictions.

There is still room for refinement of the mediation being done. Whether to virtualize the sysctl (not currently done), and what restrictions on nested user namespace should be enforced (whether a stack unconfined or system level unconfined is sufficient).

But generally speaking, what uid mappings are being done within a container are not being taken into account by the mediation. If this is something to be consider the current mediation can be extended to support it. The mediation is based on current confinement and whether the task has cap_sys_admin.

So currently it is possible to setup a container that is confined by a system level profile but unconfined within the container, and that has cap_sys_admin and have the container setup a further namespace.

If the system level confinement restricts the creation of user namespace then regardless of the application is unconfined within the container or confined and allowing access to user namespaces then access will be restricted.

There currently is a lot of flexibility in what is supported. Feedback over the next cycle or two as we refine the confinement and get things packaged up will be appreciated.

[James Lewis (james-fsck)]

Sorry, this answer has confused me even more... heres an example of what we're currently using, perhaps you can speak to that,,, the user in this case has no special rights, certainly not cap_sys_admin.

james@trinity:~$ grep james /etc/subuid
james:100000:65536
james@trinity:~$ ls -asl .local/share/lxc/2004test/rootfs/ | head -8
total 68
4 drwxr-xr-x 17 100000 100000 4096 Aug 14 2020 .
4 drwxrwx--- 3 100000 james 4096 Aug 14 2020 ..
0 lrwxrwxrwx 1 100000 100000 7 Aug 14 2020 bin -> usr/bin
4 drwxr-xr-x 2 100000 100000 4096 Apr 15 2020 boot
4 drwxr-xr-x 3 100000 100000 4096 Aug 14 2020 dev
4 drwxr-xr-x 70 100000 100000 4096 Aug 14 2020 etc
4 drwxr-xr-x 3 100000 100000 4096 Aug 14 2020 home

james@trinity:~$ whoami
james
james@trinity:~$ lxc-start -n 2004test
james@trinity:~$ lxc-attach -n 2004test
root@2004test:/# exit
exit
james@trinity:~$ lxc-stop -n 2004test
james@trinity:~$

[John Johansen (jjohansen)]

So in short yes we are talking blocking this however its not as bad as that makes it sound. There is the immediate technical side, and the reason we must do that, and then there is longer term practical use side.

So the technical short answer is yes that will be blocked at least without additional confinement. Does it suck for people who want to setup containers without using root privs. Yes. There is just no way around this, we can't only block the bad uses, there is no way to know what they are in advance. The best we can do is default deny and selectively allow. And the ability to selectively allow can't be something the attacker can do without privilege, or they have an easy way to by-pass the restriction.

With that said. It should be fairly easy to make sure there is a generic profile that will work with most lxc/lxd containers, and that can be transparent to the user. LXD already offers support for apparmor and the lxd devs are aware of the coming changes, so I expect the actual impact on your use case will be minimal to none.

And there is always the option of adjust the sysctl to disable the feature or your systems. We just can't make that a default for the distro as it isn't secure.