Open aurium opened 2 years ago
You are missing apparmor
--security-opt apparmor=unconfined
The setuid variant can potentially run as root in the container but I have not gotten that working. I discovered this while putting together a steamos container.
You are also missing the seccomp filter
--security-opt seccomp=unconfined
Docker's default seccomp filter blocks the clone
and unshare
syscalls (among others), which bubblewrap needs to create a new namespace.
Podman's seccomp filter is more permissive. Bubblewrap works (with a few limitations) in an unprivileged Podman container.
I'm experiencing the same behaviour trying out bubblewrap inside a k8s pod - even with seccomp set to Unconfined.
for me it was enough to add
--cap-add SYS_ADMIN --security-opt apparmor=unconfined --security-opt seccomp=unconfined
like advised by @s-hamann and @thelamer
bubblewrap cannot work if it's run inside a container that doesn't allow the necessary syscalls, mount operations, etc. to let bubblewrap to do its job. The precise permissions that are required are not obvious, partly because the kernel gives us very little diagnostic information when we don't have them ("Permission denied" is as much as we get).
This isn't a bubblewrap bug: doing impossible things is out-of-scope for this project.
I think it's probably a common request that I've seen me and my team looking for too: people would like to use bubblewrap (or something similar) in a confined environment (like Openshift in its default configuration for example). I guess documenting clearly what's required might both help and cut down the noise.
I am experiencing the same problems in ubuntu 24.04. I am using bwrap
in docker container. apparmor=unconfined
(included in --privileged
option) is not enough, because you are just disabling some apparmor profiles and these profiles are not ideal, if you put it mildly. Actually apparmor profiles looks like bug on the bug and main bug is driving all this construction. Solution is the following:
abi <abi/4.0>,
include <tunables/global>
profile bwrap /usr/bin/bwrap flags=(unconfined) {
userns,
include if exists <local/bwrap>
}
You need to put this code in /etc/apparmor.d/usr.bin.bwrap
(on the root machine) and run systemctl restart apparmor.service
.
@andrew-aladjev:
I am experiencing the same problems in ubuntu 24.04
Not really: you are experiencing a new, different problem that has a similar symptom.
Ubuntu has changed the Ubuntu 24.04 kernel so that programs like bubblewrap are not allowed to create a new user namespace unless they are given an AppArmor profile that contains the userns
permission. This is their choice, and if it's causing a problem for you, please report it to them. Changes in bubblewrap are not going to solve this.
A relevant Ubuntu bug is https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046844.
Ubuntu developers have said that they are intentionally not adding a profile like the one you've suggested (reference: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046844/comments/90, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046844/comments/91). What they are doing instead is adding a profile for each program that uses bubblewrap, including Flatpak, Steam, nautilus/GNOME Files (via libgnome-desktop), epiphany/GNOME Web (via WebKitGTK) and so on, as well as adding a profile for each program that does not use bubblewrap but does similar things a different way, such as Firefox and Chrome. If you are using some different program that invokes bwrap
- for example mkosi
- my understanding is that they would tell you to add a profile for that program instead of a profile for bwrap
.
I personally think their stated reasoning is flawed: they say that the reason is that giving bwrap a profile like this would allow for an arbitrary bypass of their restriction, but programs like the ones for which they are adding profiles are not designed to impose a security boundary that distrusts their caller either, so it's straightforward for an unprivileged user to bypass their restriction anyway. But I didn't design their security model, and what they choose to do in their distro is not my decision.
Ubuntu has changed the Ubuntu 24.04 kernel so that programs like bubblewrap are not allowed to create a new user namespace unless they are given an AppArmor profile that contains the userns permission. This is their choice
I wonder how long it would take for them to reconsider that choice.
I wonder how long it would take for them to reconsider that choice.
This is not Ubuntu's issue tracker and we have no control over what they do, so please take any speculation or advocacy about this to Ubuntu/Canonical issue trackers rather than here.
What they are doing instead is adding a profile for each program that uses bubblewrap, including Flatpak, Steam, nautilus/GNOME Files (via libgnome-desktop), epiphany/GNOME Web (via WebKitGTK) and so on, as well as adding a profile for each program that does not use bubblewrap but does similar things a different way, such as Firefox and Chrome. If you are using some different program that invokes bwrap - for example mkosi - my understanding is that they would tell you to add a profile for that program instead of a profile for bwrap.
It will be good to add this info into bwrap docs, despite the fact it is related to ubuntu, thank you.
bubblewrap is becoming a popular sandbox tool, so we need be able to use it inside unprivileged docker to containerize solutions.
As you may know
bwrap
works correctly in a privileged container:You also may know that wont work with a simple
--privileged
removal:Now lets try to give all permissions, then when we succeed, we can remove one by one to use only the necessary capabilities:
To be sure I ran
capsh --print
on both--privileged
try and on the all--cap-add
try. Both give me the same result:Failed to make / slave: Permission denied
" result?