---
title: Restricted unprivileged user namespaces are coming to Ubuntu 23.10
description: Learn about the new security feature coming to Ubuntu 23.10, Restricted
  Unprivileged User Namespaces, and how it enhances security while balancing usability.
  Discover how AppArmor is used to selectively control access and mitigate potential
  risks in this blog post.
url: https://canonical.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces?format=md
---

1. [Blog](https://canonical.com/blog)
2. Article

---

[Ijlal Loutfi](https://canonical.com/blog/author/ijlal-loutfi "More about Ijlal Loutfi")

9 October 2023

# Restricted unprivileged user namespaces are coming to Ubuntu 23.10

[Security](https://canonical.com/blog/tag/security)
[Ubuntu 23.10](https://canonical.com/blog/tag/ubuntu-23-10)
[Ubuntu Desktop](https://canonical.com/blog/tag/ubuntu-desktop)
[Ubuntu Server](https://canonical.com/blog/tag/ubuntu-server)

---

Share the article

Ubuntu Desktop firmly places security at the forefront, and adheres to the [principles of security by default.](https://ubuntu.com/blog/ubuntu-desktop-charting-a-course-for-the-future) This approach caters to both everyday users and organisations with specific compliance requirements. As such, Ubuntu ensures that its recommended security configurations are equally robust, easy to understand and readily accessible as part of the default user experience.

Striking such a delicate balance between security and usability is what has guided our design for restricted unprivileged user namespaces, which is a new security feature that is coming to Ubuntu 23.10. On release day, the feature will be opt-in and you will be able to turn it on using the command line. As we collect more feedback from our users, we will then turn it on by default, on 23.10, using the SRU process.

In this blog post, we will provide an overview of what unprivileged user namespaces are, discuss Ubuntu’s approach to mitigating their security risks, and explain how to start using this feature today and provide us with your feedback.

# What are the security risks of unprivileged user namespaces?

Unprivileged user namespaces are a feature of the kernel that can be used to replace many of the uses of setuid and setguid programs (short for set user identity and set group identity), and allow for applications to create more secure sandboxes. However, they expose kernel interfaces that are normally restricted to processes with privileged capabilities (root) to use by unprivileged users.

Exposing more kernel interfaces than necessary to a process introduces
additional security risks, and unfortunately unprivileged user
namespaces are now broadly used as a step in several privilege
escalation exploit chains. In fact, even if unprivileged user namespaces
are bug free, as long as any privileged kernel interface or combination
of interfaces has a bug, an unprivileged user can try to exploit that
bug. In a report from Google, [44% of the exploits](https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html) they saw required unprivileged user namespaces as part of their exploit chain.

# How can we mitigate this risk?

Several distro kernels carry a patch that allows for a [sysctl to disable unprivileged user namespaces](https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction#disabling-unprivileged-user-namespaces) as a mitigation. Unfortunately the sysctl is all or nothing. While disabling unprivileged user namespaces might stop an exploit, it can also break applications that use them. Generally an exploit targets a specific application, and as long as unprivileged user namespaces can be disabled for those applications there is no need to disable them for the entire system

## Ubuntu’s approach

Therefore, for Ubuntu, we are introducing [restricted unprivileged user namespaces](https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626), where AppArmor can be used to selectively allow and disallow unprivileged user namespaces. An AppArmor policy is used to selectively control access to unprivileged user namespaces on a per applications basis.

As such, unprivileged processes will only be able to create user namespaces if they are confined and have the “userns,” rule in their AppArmor profile (or if they have CAP\_SYS\_ADMIN). Since it is not feasible to create a complete AppArmor profile for most affected applications, we introduced a new *default\_allow* profile mode. While this effectively allows the application to remain unconfined, it also *adds a new “userns,” rule* to allow it to use unprivileged user namespaces. An example of such a profile can be seen below (this would be provided by the AppArmor profile file /etc/apparmor.d/opt.google.chrome.chrome in this case):

> abi <abi/4.0>,
>
> include <tunables/global>
>
> /opt/google/chrome/chrome flags=(default\_allow) {
>   userns,
>
>   # Site-specific additions and overrides. See local/README for details.
>   include if exists <local/opt.google.chrome.chrome>
> }

## What have we done so far?

This change impacts some programs like Firefox, Chrome, and many more. We have surveyed the Ubuntu archives and listed the applications which we believe will be impacted. For those, we are writing AppArmor profiles which allow them to continue using unprivileged user namespaces.

Furthermore, we also plan to add the profiles in the apparmor binary package, as compared to say apparmor-profiles or within the debs for these affected applications themselves.  For Chrome, for instance, this will cover the /opt/google/chrome/chrome binary. So assuming all the various chrome debs install to this same path then they should be covered as well.

This will give us more control over them and hopefully allows us to also cover the case where a user installs from some other source – if they are using AppArmor then they will automatically have a profile for the affected application.

## What is missing and where can you help?

The mitigation above described (supplying profiles in the AppArmor package) is not (and may never be) complete, and applications that use unprivileged user namespaces may be denied from using them if:

1. No AppArmor profile exists for them (ie: packages not in the Ubuntu archives or for which a profile has not been provided); and/or
2. They get installed at a different path

The best way forward is for the vendors/developers themselves to provide an AppArmor profile that they ship with their software for each Ubuntu release.

This feature will be first available as an opt-in in Ubuntu 23.10 We invite everybody to experiment with it, and to [report a bug](https://bugs.launchpad.net/ubuntu/+source/apparmor/+filebug) if they know or suspect an application is breaking because of this change. As we collect more feedback from you throughout the first couple of weeks of the 23.10 lifetime, we will build more AppArmor profiles for more apps, and then turn this feature on by default on 23.10,  through the [SRU process](https://wiki.ubuntu.com/StableReleaseUpdates) (Stable Release Updates).

In order to turn this feature on, use the following command:

> sudo sysctl -w kernel.apparmor\_restrict\_unprivileged\_unconfined=1
> sudo sysctl -w kernel.apparmor\_restrict\_unprivileged\_userns=1

And if you want to disable it, run the following two commands:

> sudo sysctl -w kernel.apparmor\_restrict\_unprivileged\_unconfined=0
> sudo sysctl -w kernel.apparmor\_restrict\_unprivileged\_userns=0

We also note that no prior Ubuntu release will be impacted by this change, even when using the 6.5 kernel as a Hardware Enablement Kernel with older LTS releases, since the feature is not enabled in the kernel directly but within the apparmor package specific to the  Ubuntu 23.10 release.

## **Other resources**

* [Engineering Specification](https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626)
* [Ubuntu daily builds](https://cdimage.ubuntu.com/daily-live/)
* [Mantic Minotaur release notes](https://discourse.ubuntu.com/t/mantic-minotaur-release-notes/35534)
* [Ubuntu Desktop discourse](https://discourse.ubuntu.com/c/desktop/8)
* [Learn more about AppArmor](https://ubuntu.com/engage/apparmor-intro)
* [How to build an AppArmor profile](https://ubuntu.com/tutorials/beginning-apparmor-profile-development#1-overview)
* [Learn about the value of Ubuntu desktop](https://ubuntu.com/blog/ubuntu-desktop-charting-a-course-for-the-future)

## Sign up for our newsletter

Get the latest Canonical news and updates in your inbox.

Work email:

\*I agree to receive information about Canonical's
products and services.

By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/dataprivacy).

Sign up

## Share on

---

## Related posts

[### Canonical joins the Open Secure AI Alliance](https://canonical.com/blog/open-secure-ai-alliance)

Canonical is now part of the Open Secure AI Alliance, announced by NVIDIA with partners across cloud computing, cybersecurity, enterprise software, open source foundations, and...

[Canonical](https://canonical.com/blog/author/canonical)

28 August 2026

[### Arduino® VENTUNO™ Q is available for pre-order with Ubuntu pre-installed](https://canonical.com/blog/arduino-ventuno-q-is-available-for-pre-order-with-ubuntu-pre-installed)

London, UK – August 25, 2026 – Following our initial collaboration announcement in March 2026, Canonical and Arduino (a subsidiary of Qualcomm Technologies, Inc.) are excited...

[Canonical](https://canonical.com/blog/author/canonical)

25 August 2026

[### Januscape vulnerability CVE-2026-53359 mitigations available](https://canonical.com/blog/januscape-linux-vulnerability-mitigations-available)

Introduction A local privilege escalation (LPE) vulnerability affecting the Linux kernel was publicly disclosed on July 6, 2026. The vulnerability was assigned CVE ID...

[seth-arnold](https://canonical.com/blog/author/seth-arnold)

11 July 2026

[### Ubuntu Server: a platform made for enterprise scale](https://canonical.com/blog/ubuntu-server-a-platform-made-for-enterprise-scale)

A platform is an environment that allows software to run smoothly across the infrastructure, runtime, and application layers. The key word there is “smoothly”: a good platform...

[Rhys Knipe](https://canonical.com/blog/author/rhysknipe)

7 July 2026
