Tomasz Duda c43ea7d629 exeseal: do not use F_SEAL_FUTURE_WRITE ...

Prior to kernel Linux 5.5, F_SEAL_FUTURE_WRITE has a bug which maps
memory as shared between processes even if it is set as private. See
kernel commit 05d351102dbe ("mm, memfd: fix COW issue on MAP_PRIVATE and
F_SEAL_FUTURE_WRITE mappings") for more details.

According to the fcntl(2) man pages, F_SEAL_WRITE is enough:

> Furthermore, trying to create new shared, writable memory-mappings via
> mmap(2) will also fail with EPERM.
>
> Using the F_ADD_SEALS operation to set the F_SEAL_WRITE seal fails
> with EBUSY if any writable, shared mapping exists. Such mappings must
> be unmapped before you can add this seal.

F_SEAL_FUTURE_WRITE only makes sense if a read-write shared mapping in
one process should be read-only in another process. This is not case for
runc, especially not for the /proc/self/exe we are protecting.

Signed-off-by: Tomasz Duda <tomaszduda23@gmail.com>
(cyphar: improve the comment regarding F_SEAL_FUTURE_WRITE)
(cyphar: improve commit message)
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

2025-02-26 16:40:34 +11:00

..

cloned_binary_linux.go

exeseal: do not use F_SEAL_FUTURE_WRITE

2025-02-26 16:40:34 +11:00

overlayfs_linux.go

libcontainer: rename dmz -> exeseal

2025-02-25 13:46:05 +11:00