README.md

memfd-bind

runc normally has to make a binary copy of itself (or of a smaller helper binary called runc-dmz) when constructing a container process in order to defend against certain container runtime attacks such as CVE-2019-5736.

This cloned binary only exists until the container process starts (this means for runc run and runc exec, it only exists for a few hundred milliseconds -- for runc create it exists until runc start is called). However, because the clone is done using a memfd (or by creating files in directories that are likely to be a tmpfs), this can lead to temporary increases in host memory usage. Unless you are running on a cgroupv1 system with the cgroupv1 memory controller enabled and the (deprecated) memory.move_charge_at_immigrate enabled, there is no effect on the container's memory.

However, for certain configurations this can still be undesirable. This daemon allows you to create a sealed memfd copy of the runc binary, which will cause runc to skip all binary copying, resulting in no additional memory usage for each container process (instead there is a single in-memory copy of the binary). It should be noted that (strictly speaking) this is slightly less secure if you are concerned about Dirty Cow-like 0-day kernel vulnerabilities, but for most users the security benefit is identical.

The provided memfd-bind@.service file can be used to get systemd to manage this daemon. You can supply the path like so:

% systemctl start memfd-bind@/usr/bin/runc

Thus, there are three ways of protecting against CVE-2019-5736, in order of how much memory usage they can use:

• memfd-bind only creates a single in-memory copy of the runc binary (about 10MB), regardless of how many containers are running.

• runc-dmz is (depending on which libc it was compiled with) between 10kB and 1MB in size, and a copy is created once per process spawned inside a container by runc (both the pid1 and every runc exec). The RUNC_DMZ=true environment variable needs to be set to opt-in. There are circumstances where using runc-dmz will fail in ways that runc cannot predict ahead of time (such as restrictive LSMs applied to containers). runc-dmz also requires an additional execve over the other options, though since the binary is so small the cost is probably not even noticeable.

• The classic method of making a copy of the entire runc binary during container process setup takes up about 10MB per process spawned inside the container by runc (both pid1 and runc exec).

Caveats

There are several downsides with using memfd-bind on the runc binary:

• The memfd-bind process needs to continue to run indefinitely in order for the memfd reference to stay alive. If the process is forcefully killed, the bind-mount on top of the runc binary will become stale and nobody will be able to execute it (you can use memfd-bind --cleanup to clean up the stale mount).

• Only root can execute the cloned binary due to permission restrictions on accessing other process's files. More specifically, only users with ptrace privileges over the memfd-bind daemon can access the file (but in practice this is usually only root).

• When updating runc, the daemon needs to be stopped before the update (so the package manager can access the underlying file) and then restarted after the update.