|
1 |
| -# Sysbox User Guide: Design Notes |
| 1 | +# Sysbox-EE User Guide: Design Notes |
2 | 2 |
|
3 | 3 | This document briefly describes some aspects of Sysbox's design.
|
4 | 4 |
|
@@ -31,18 +31,17 @@ mounts inside the system container. It's purpose is to make the system container
|
31 | 31 | closely resemble a virtual host while ensuring proper isolation from the rest of
|
32 | 32 | the system.
|
33 | 33 |
|
34 |
| -sysbox-mgr is a daemon that provides services to sysbox-runc and |
35 |
| -sysbox-fs. For example, it manages assignment of exclusive user |
36 |
| -namespace user-ID and group-ID mappings to system containers, manages |
37 |
| -some special mounts that Sysbox adds to system containers, etc. |
| 34 | +sysbox-mgr is a daemon that provides services to sysbox-runc and sysbox-fs. For |
| 35 | +example, it manages assignment user-ID and group-ID mappings to system |
| 36 | +containers, manages some special mounts that Sysbox adds to system containers, |
| 37 | +etc. |
38 | 38 |
|
39 |
| -Together, sysbox-fs and sysbox-mgr are the "back-ends" for |
40 |
| -sysbox. Communication between the sysbox components is done via |
41 |
| -gRPC. |
| 39 | +Together, sysbox-fs and sysbox-mgr are the "back-ends" for sysbox. Communication |
| 40 | +between the sysbox components is done via gRPC. |
42 | 41 |
|
43 |
| -Users don't normally interact with the Sysbox components directly. |
44 |
| -Instead, they use higher level apps (e.g., Docker) that interact with |
45 |
| -Sysbox to deploy system containers. |
| 42 | +Users don't normally interact with the Sysbox components directly. Instead, |
| 43 | +they use higher level apps (e.g., Docker) that interact with Sysbox to deploy |
| 44 | +system containers. |
46 | 45 |
|
47 | 46 | ## Ubuntu Shiftfs Module
|
48 | 47 |
|
@@ -106,11 +105,11 @@ For example, an attacker running inside the system container can
|
106 | 105 | create set-user-ID-root executables which can then be executed by
|
107 | 106 | non-root users on the host to gain root privileges.
|
108 | 107 |
|
109 |
| -Note that this vulnerability is not specific to Nestybox system |
110 |
| -containers or shiftfs; the same attack is possible with regular Docker |
111 |
| -containers because in those the root user in the container is in fact |
112 |
| -the root user on the host, so files written by the root user in the |
113 |
| -container have `root:root` ownership on the host. |
| 108 | +Note that this vulnerability is not specific to system containers or shiftfs; |
| 109 | +the same attack is possible with regular Docker containers because in those the |
| 110 | +root user in the container is in fact the root user on the host, so files |
| 111 | +written by the root user in the container have `root:root` ownership on the |
| 112 | +host. |
114 | 113 |
|
115 | 114 | To reduce the attack surface, the following security precautions are
|
116 | 115 | recommended:
|
@@ -188,9 +187,9 @@ Kubernetes and containerd work properly inside the system container.
|
188 | 187 | Sysbox is a fork of the [OCI runc](https://github.com/opencontainers/runc). It is mostly
|
189 | 188 | (but not 100%) compatible with the OCI runtime specification.
|
190 | 189 |
|
191 |
| -The incompatibilities arise from Nestybox's desire to make deployment |
192 |
| -of system containers possible with Docker (to save users the trouble |
193 |
| -of having to learn yet another tool). |
| 190 | +The incompatibilities arise from our desire to make deployment of system |
| 191 | +containers possible with Docker (to save users the trouble of having to learn |
| 192 | +yet another tool). |
194 | 193 |
|
195 | 194 | We believe these incompatibilities won't negatively affect users of
|
196 | 195 | Sysbox and should mostly be transparent to them.
|
|
0 commit comments