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>
(cherry picked from commit ac435895b9)
Signed-off-by: lfbzhm <lifubang@acmcoder.com>
This commit is contained in:
Aleksa Sarai
2024-11-13 01:19:46 +11:00
committed by Kir Kolyshkin
parent 82f3af8553
commit eb676de151

View File

@@ -1,13 +1,13 @@
## memfd-bind ##
> **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
> memfd-bind, and for most users this should obviate the need for `memfd-bind`
> entirely. Rootless containers will still make a memfd copy (unless you are
> using `runc` itself inside a user namespace -- a-la
> [`rootlesskit`][rootlesskit]), but `memfd-bind` is not particularly useful
> for rootless container users anyway (see [Caveats](#Caveats) for more
> details).
> protect the runc binary (if you are on Linux 5.1 or later). This protection
> is far more light-weight than memfd-bind, and for most users this should
> obviate the need for `memfd-bind` entirely. Rootless containers will still
> make a memfd copy (unless you are using `runc` itself inside a user namespace
> -- a-la [`rootlesskit`][rootlesskit] -- and are on Linux 5.11 or later), but
> `memfd-bind` is not particularly useful for rootless container users anyway
> (see [Caveats](#Caveats) for more details).
`runc` sometimes has to make a binary copy of itself when constructing a
container process in order to defend against certain container runtime attacks