Re: [PATCH v7 5/7] fs,doc: Enable to enforce noexec mounts or file exec through O_MAYEXEC
From: Kees Cook <hidden>
Date: 2020-07-24 19:03:27
Also in:
linux-fsdevel, linux-integrity, linux-security-module, lkml
On Thu, Jul 23, 2020 at 07:12:25PM +0200, Mickaël Salaün wrote:
Allow for the enforcement of the O_MAYEXEC openat2(2) flag. Thanks to the noexec option from the underlying VFS mount, or to the file execute permission, userspace can enforce these execution policies. This may allow script interpreters to check execution permission before reading commands from a file, or dynamic linkers to allow shared object loading. Add a new sysctl fs.open_mayexec_enforce to enable system administrators to enforce two complementary security policies according to the installed system: enforce the noexec mount option, and enforce executable file permission. Indeed, because of compatibility with installed systems, only system administrators are able to check that this new enforcement is in line with the system mount points and file permissions. A following patch adds documentation. Being able to restrict execution also enables to protect the kernel by restricting arbitrary syscalls that an attacker could perform with a crafted binary or certain script languages. It also improves multilevel isolation by reducing the ability of an attacker to use side channels with specific code. These restrictions can natively be enforced for ELF binaries (with the noexec mount option) but require this kernel extension to properly handle scripts (e.g., Python, Perl). To get a consistent execution policy, additional memory restrictions should also be enforced (e.g. thanks to SELinux). Because the O_MAYEXEC flag is a meant to enforce a system-wide security policy (but not application-centric policies), it does not make sense for userland to check the sysctl value. Indeed, this new flag only enables to extend the system ability to enforce a policy thanks to (some trusted) userland collaboration. Moreover, additional security policies could be managed by LSMs. This is a best-effort approach from the application developer point of view: https://lore.kernel.org/lkml/1477d3d7-4b36-afad-7077-a38f42322238@digikod.net/ (local) Signed-off-by: Mickaël Salaün <mic@digikod.net>
Acked-by: Kees Cook <redacted> -- Kees Cook