Add --disable-userns switch #452

alexlarsson · 2021-10-08T12:04:15Z

Some usecases of bubblewrap want to ensure that the subprocess can't
further re-arrange the filesystem namespace, or do other more complex
namespace modification. This can be limited by --disable-userns,
which makes the kernel unable to create any new user namespaces
for the process hierarchy.

This is done by making a cover of the original root, but running the
process with the origin root as root anyway. This "non-standard" root
means the kernel will not allow creating new user namespaces.

This is more typically done using chroot("/theroot") which would also
mean the root of the namespace ("/") differes from the process current
root ("/theroot)". However, we want to avoid this as in this case symlinks
in /proc/$pid/fd would have a "/theroot" prefix when seen outside the
namespace, which is something that e.g. flatpak doesn't want.

Note, there is a slight cost to this as the covering bind mount
duplicates all the regular mounts in namespace. However, they all
refer to the same mounts so no actual files are duplicated.

Some usecases of bubblewrap want to ensure that the subprocess can't further re-arrange the filesystem namespace, or do other more complex namespace modification. This can be limited by --disable-userns, which makes the kernel unable to create any new user namespaces for the process hierarchy. This is done by making a cover of the original root, but running the process with the origin root as root anyway. This "non-standard" root means the kernel will not allow creating new user namespaces. This is more typically done using chroot("/theroot") which would also mean the root of the namespace ("/") differes from the process current root ("/theroot)". However, we want to avoid this as in this case symlinks in /proc/$pid/fd would have a "/theroot" prefix when seen outside the namespace, which is something that e.g. flatpak doesn't want. Note, there is a slight cost to this as the covering bind mount duplicates all the regular mounts in namespace. However, they all refer to the same mounts so no actual files are duplicated.

alexlarsson · 2021-10-08T12:05:14Z

This was initially discussed in https://github.com/flatpak/flatpak/security/advisories/GHSA-67h7-w3jq-vh4q#advisory-comment-68447

smcv · 2021-10-08T20:22:02Z

Sorry, I don't have the necessary knowledge of kernel subtleties to review this.

mcatanzaro · 2021-10-10T12:27:48Z

bubblewrap.c

+    {
+      if (using_userns2)
+        {
+          /* If we're not in the main userns, the we don't own the


smcv · 2021-10-12T11:37:46Z

bubblewrap.c

+      /* Mount a bind cover of the root fs. This will trigger
+       * current_chrooted() in create_user_ns() in the kernel at:
+       *   https://elixir.bootlin.com/linux/v5.14.4/source/kernel/user_namespace.c#L92
+       * making it impossible for the process to create new user namespaces.


Is this an API guarantee that we can rely on, or an implementation detail that kernel developers could randomly change in a future version (thus making us vulnerable again)?

I believe this behavior is stable API, because it is fundamental in exposing user namespaces in a secure way.

lukts30 · 2022-02-18T15:20:50Z

Wouldn't it be more straightforward to use the max_user_namespaces sysctl?

If the user namespace is a child of the initial user namespace you could of course bump the max_user_namespaces value from 0 back up if are privileged to write to that sysctl.

But you can create an intermediary user namespace set the limit to 1 and then create the user namespace for the actual program to run in. Inside this user namespace, it is still possible to set the sysctl to some large number but the kernel enforces that any stricter max value in a parent namespace is enforced.

[lukas@PC      ~]$ sysctl user.max_user_namespaces
user.max_user_namespaces = 128026
[lukas@PC      ~]$ unshare -Ur bash
[root@PC      ~]# sysctl user.max_user_namespaces
user.max_user_namespaces = 2147483647
[root@PC      ~]# sysctl -w user.max_user_namespaces=1
user.max_user_namespaces = 1
[root@PC      ~]# unshare -Ur bash
[root@PC      ~]# sysctl user.max_user_namespaces
user.max_user_namespaces = 2147483647
[root@PC      ~]# unshare -Ur bash
unshare: unshare failed: No space left on device

rusty-snake · 2022-02-18T15:28:28Z

bubblewrap.c

+       *   https://elixir.bootlin.com/linux/v5.14.4/source/kernel/user_namespace.c#L92
+       * making it impossible for the process to create new user namespaces.
+       *
+       * What happens is that the path "/" in the namespace noew


Suggested change

* What happens is that the path "/" in the namespace noew

* What happens is that the path "/" in the namespace now

smcv · 2022-03-22T15:54:09Z

Wouldn't it be more straightforward to use the max_user_namespaces sysctl?

This looks like a simpler way to achieve the same thing. I might try implementing it if you don't get there first.

Some use-cases of bubblewrap want to ensure that the subprocess can't further re-arrange the filesystem namespace, or do other more complex namespace modification. For example, Flatpak wants to prevent sandboxed processes from altering their /proc/$pid/root/.flatpak-info, so that /.flatpak-info can safely be used as an indicator that a process is part of a Flatpak app. This approach was suggested by lukts30 on containers#452. The sysctl-controlled maximum numbers of namespaces are themselves namespaced, so we can disable nested user namespaces by setting the limit to 1 and then entering a new, nested user namespace. The resulting process loses its privileges in the namespace where the limit was set to 1, so it is unable to move the limit back up. Signed-off-by: Simon McVittie <smcv@collabora.com>

smcv · 2022-03-22T17:51:51Z

Wouldn't it be more straightforward to use the max_user_namespaces sysctl?

This looks like a simpler way to achieve the same thing.

#488 reimplements this feature with that approach.

Some use-cases of bubblewrap want to ensure that the subprocess can't further re-arrange the filesystem namespace, or do other more complex namespace modification. For example, Flatpak wants to prevent sandboxed processes from altering their /proc/$pid/root/.flatpak-info, so that /.flatpak-info can safely be used as an indicator that a process is part of a Flatpak app. This approach was suggested by lukts30 on containers#452. The sysctl-controlled maximum numbers of namespaces are themselves namespaced, so we can disable nested user namespaces by setting the limit to 1 and then entering a new, nested user namespace. The resulting process loses its privileges in the namespace where the limit was set to 1, so it is unable to move the limit back up. Signed-off-by: Simon McVittie <smcv@collabora.com>

alexlarsson · 2022-09-06T07:40:45Z

closing this in favour of #488

Some use-cases of bubblewrap want to ensure that the subprocess can't further re-arrange the filesystem namespace, or do other more complex namespace modification. For example, Flatpak wants to prevent sandboxed processes from altering their /proc/$pid/root/.flatpak-info, so that /.flatpak-info can safely be used as an indicator that a process is part of a Flatpak app. This approach was suggested by lukts30 on containers#452. The sysctl-controlled maximum numbers of namespaces are themselves namespaced, so we can disable nested user namespaces by setting the limit to 1 and then entering a new, nested user namespace. The resulting process loses its privileges in the namespace where the limit was set to 1, so it is unable to move the limit back up. Co-authored-by: Alexander Larsson <alexl@redhat.com> Signed-off-by: Simon McVittie <smcv@collabora.com>

Some use-cases of bubblewrap want to ensure that the subprocess can't further re-arrange the filesystem namespace, or do other more complex namespace modification. For example, Flatpak wants to prevent sandboxed processes from altering their /proc/$pid/root/.flatpak-info, so that /.flatpak-info can safely be used as an indicator that a process is part of a Flatpak app. This approach was suggested by lukts30 on #452. The sysctl-controlled maximum numbers of namespaces are themselves namespaced, so we can disable nested user namespaces by setting the limit to 1 and then entering a new, nested user namespace. The resulting process loses its privileges in the namespace where the limit was set to 1, so it is unable to move the limit back up. Co-authored-by: Alexander Larsson <alexl@redhat.com> Signed-off-by: Simon McVittie <smcv@collabora.com>

Some use-cases of bubblewrap want to ensure that the subprocess can't further re-arrange the filesystem namespace, or do other more complex namespace modification. For example, Flatpak wants to prevent sandboxed processes from altering their /proc/$pid/root/.flatpak-info, so that /.flatpak-info can safely be used as an indicator that a process is part of a Flatpak app. This approach was suggested by lukts30 on containers#452. The sysctl-controlled maximum numbers of namespaces are themselves namespaced, so we can disable nested user namespaces by setting the limit to 1 and then entering a new, nested user namespace. The resulting process loses its privileges in the namespace where the limit was set to 1, so it is unable to move the limit back up. Co-authored-by: Alexander Larsson <alexl@redhat.com> Signed-off-by: Simon McVittie <smcv@collabora.com>

smcv requested a review from cgwalters October 8, 2021 20:13

smcv mentioned this pull request Oct 9, 2021

Handle syscalls via allowlist instead of denylist flatpak/flatpak#4462

Draft

mcatanzaro reviewed Oct 10, 2021

View reviewed changes

bubblewrap.c

{

if (using_userns2)

{

/* If we're not in the main userns, the we don't own the

Copy link

mcatanzaro Oct 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then

smcv reviewed Oct 12, 2021

View reviewed changes

rusty-snake reviewed Feb 18, 2022

View reviewed changes

smcv mentioned this pull request Mar 22, 2022

Add an option to disable nested user namespaces by setting limit to 1 #488

Merged

smcv mentioned this pull request Mar 22, 2022

Performance impact of seccomp filter in games flatpak/flatpak#4187

Open

alexlarsson closed this Sep 6, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add --disable-userns switch #452

Add --disable-userns switch #452

alexlarsson commented Oct 8, 2021

alexlarsson commented Oct 8, 2021

smcv commented Oct 8, 2021

mcatanzaro Oct 10, 2021

smcv Oct 12, 2021

alexlarsson Oct 12, 2021

lukts30 commented Feb 18, 2022

rusty-snake Feb 18, 2022

smcv commented Mar 22, 2022

smcv commented Mar 22, 2022

alexlarsson commented Sep 6, 2022

	* What happens is that the path "/" in the namespace noew
	* What happens is that the path "/" in the namespace now

Add --disable-userns switch #452

Add --disable-userns switch #452

Conversation

alexlarsson commented Oct 8, 2021

alexlarsson commented Oct 8, 2021

smcv commented Oct 8, 2021

mcatanzaro Oct 10, 2021

Choose a reason for hiding this comment

smcv Oct 12, 2021

Choose a reason for hiding this comment

alexlarsson Oct 12, 2021

Choose a reason for hiding this comment

lukts30 commented Feb 18, 2022

rusty-snake Feb 18, 2022

Choose a reason for hiding this comment

smcv commented Mar 22, 2022

smcv commented Mar 22, 2022

alexlarsson commented Sep 6, 2022