Simon McVittie

Normally, bubblewrap users run code inside the container as a uid that differs from the owner of the bubblewrap executable, in which case there's no problem. For instance, if uid...

> If I understand this correctly flatpak/flatpak@cd21428 using --proc will resolve this issue. Is that correct? I think so, but I don't have a reproducer for the Flatpak vulnerability, so...

> If I understand this correctly flatpak/flatpak@cd21428 using --proc will resolve this issue. Is that correct? Looking again: No, it's the opposite. The solution used in Flatpak was ensuring that...

One feature request that might help, if people need to run bwrap as real uid 0, would be an option to map the `--uid` inside the container to a different...

> Seems like I misunderstood the --proc option. I assumed that it worked like the --dev option and provided a reduced /proc environment. It sort of does, but there's a...

> What about the case where the container does have real UID 0, but Mandatory Access Control (SELinux/AppArmor/SMACK/etc) is enforcing and prevents the container from having access to things that...

> But a suid bwrap could run `sysctl kernel.unprivileged_userns_clone=1`, drop privs and start the second sandbox/user namespace That would allow any process, including potential attackers, to create new user namespaces....

> The ideal solution I could think of would be a capability to allow the use of user namespaces for the enabled binaries only. Part of what is necessary to...

The ideal solution would be for distribution maintainers to be confident that allowing unprivileged creation of new user namespaces is not going to introduce a security vulnerability. Unfortunately, according to...

> user namespace capability is used on all sandbox tools (bwrap, chrome-sandbox etc.) allowing bwrap to run as unprivileged* process with the option to not drop this capability to allow...