memfd-bind: elaborate kernel requirements for overlayfs protection

Arguably these docs should live elsewhere (especially if we plan to
remove memfd-bind in the future), but for now this is the only place
that fully explains this issue.

Suggested-by: Rodrigo Campos <rodrigoca@microsoft.com>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This commit is contained in:
Aleksa Sarai
2024-11-13 01:19:46 +11:00
parent eb596b8d3b
commit ac435895b9
+7 -7
View File
@@ -1,13 +1,13 @@
## memfd-bind ## ## memfd-bind ##
> **NOTE**: Since runc 1.2.0, runc will now use a private overlayfs mount to > **NOTE**: Since runc 1.2.0, runc will now use a private overlayfs mount to
> protect the runc binary. This protection is far more light-weight than > protect the runc binary (if you are on Linux 5.1 or later). This protection
> memfd-bind, and for most users this should obviate the need for `memfd-bind` > is far more light-weight than memfd-bind, and for most users this should
> entirely. Rootless containers will still make a memfd copy (unless you are > obviate the need for `memfd-bind` entirely. Rootless containers will still
> using `runc` itself inside a user namespace -- a-la > make a memfd copy (unless you are using `runc` itself inside a user namespace
> [`rootlesskit`][rootlesskit]), but `memfd-bind` is not particularly useful > -- a-la [`rootlesskit`][rootlesskit] -- and are on Linux 5.11 or later), but
> for rootless container users anyway (see [Caveats](#Caveats) for more > `memfd-bind` is not particularly useful for rootless container users anyway
> details). > (see [Caveats](#Caveats) for more details).
`runc` sometimes has to make a binary copy of itself when constructing a `runc` sometimes has to make a binary copy of itself when constructing a
container process in order to defend against certain container runtime attacks container process in order to defend against certain container runtime attacks