1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
Bubblewrap
==========
Many container runtime tools like `systemd-nspawn`, `docker`,
etc. focus on providing infrastructure for system administrators and
orchestration tools (e.g. Kubernetes) to run containers.
These tools are not suitable to give to unprivileged users, because it
is trivial to turn such access into to a fully privileged root shell
on the host.
There is an effort in the Linux kernel called
[user namespaces](https://www.google.com/search?q=user+namespaces+site%3Ahttps%3A%2F%2Flwn.net)
which attempts to allow unprivileged users to use container features.
While significant progress has been made, there are
[still concerns](https://lwn.net/Articles/673597/) about it.
Bubblewrap is a setuid implementation of a *subset* of user
namespaces. (Emphasis on subset)
It inherits code from
[xdg-app helper](https://cgit.freedesktop.org/xdg-app/xdg-app/tree/common/xdg-app-helper.c)
which in turn distantly derives from
[linux-user-chroot](https://git.gnome.org/browse/linux-user-chroot).
Security
--------
The maintainers of this tool believe that it does not, even when used
in combination with typical software installed on that distribution,
allow privilege escalation. It may increase the ability of a logged
in user to perform denial of service attacks, however.
In particular, bubblewrap uses `PR_SET_NO_NEW_PRIVS` to turn off
setuid binaries.
Users
-----
This program can be shared by all container tools which perform
non-root operation, such as:
- [xdg-app](https://cgit.freedesktop.org/xdg-app/xdg-app)
- [rpm-ostree unprivileged](https://github.com/projectatomic/rpm-ostree/pull/209)
We would also like to see this be available in Kubernetes/OpenShift
clusters. Having the ability for unprivileged users to use container
features would make it significantly easier to do interactive
debugging scenarios and the like.
Usage
-----
bubblewrap works by creating a new, completely empty, filesystem
namespace where the root is on a tmpfs that is invisible from the
host, and will be automatically cleaned up when the last process
exists. You can then use commandline options to construct the root
filesystem and process environment and command to run in the
namespace.
A simple example is
```
bwrap --ro-bind / / bash
```
This will create a read-only bind mount of the host root at the
sandbox root, and then start a bash.
Another simple example would be a read-write chroot operation:
```
bwrap --bind /some/chroot/dir / bash
```
A more complex example is to run a with a custom (readonly) /usr,
but your own (tmpfs) data, running in a PID and network namespace:
```
bwrap --ro-bind /usr /usr \
--dir /tmp \
--proc /proc \
--dev /dev \
--ro-bind /etc/resolv.conf /etc/resolv.conf \
--symlink usr/lib /lib \
--symlink usr/lib64 /lib64 \
--symlink usr/bin /bin \
--symlink usr/sbin /sbin \
--chdir / \
--unshare-pid \
--unshare-net \
--dir /run/user/$(id -u) \
--setenv XDG_RUNTIME_DIR "/run/user/`id -u`" \
/bin/sh
```
Whats with the name ?!
----------------------
The name bubblewrap was chosen to convey that this
tool runs as the parent of the application (so wraps it in some sense) and creates
a protective layer (the sandbox) around it.
(Bubblewrap cat by [dancing_stupidity](https://www.flickr.com/photos/27549668@N03/))
|
