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@xxxxxxxxxxx/ > > Signed-off-by: Mickaël Salaün <mic@xxxxxxxxxxx> Acked-by: Kees Cook <keescook@xxxxxxxxxxxx> -- Kees Cook
