On Thu, Jul 23, 2020 at 07:12:24PM +0200, Mickaël Salaün wrote: > When the O_MAYEXEC flag is passed, openat2(2) may be subject to > additional restrictions depending on a security policy managed by the > kernel through a sysctl or implemented by an LSM thanks to the > inode_permission hook. This new flag is ignored by open(2) and > openat(2) because of their unspecified flags handling. When used with > openat2(2), the default behavior is only to forbid to open a directory. > > The underlying idea is to be able to restrict scripts interpretation > according to a policy defined by the system administrator. For this to > be possible, script interpreters must use the O_MAYEXEC flag > appropriately. To be fully effective, these interpreters also need to > handle the other ways to execute code: command line parameters (e.g., > option -e for Perl), module loading (e.g., option -m for Python), stdin, > file sourcing, environment variables, configuration files, etc. > According to the threat model, it may be acceptable to allow some script > interpreters (e.g. Bash) to interpret commands from stdin, may it be a > TTY or a pipe, because it may not be enough to (directly) perform > syscalls. Further documentation can be found in a following patch. > > Even without enforced security policy, userland interpreters can set it > to enforce the system policy at their level, knowing that it will not > break anything on running systems which do not care about this feature. > However, on systems which want this feature enforced, there will be > knowledgeable people (i.e. sysadmins who enforced O_MAYEXEC > deliberately) to manage it. A simple security policy implementation, > configured through a dedicated sysctl, is available in a following > patch. > > O_MAYEXEC should not be confused with the O_EXEC flag which is intended > for execute-only, which obviously doesn't work for scripts. However, a > similar behavior could be implemented in userland with O_PATH: > https://lore.kernel.org/lkml/1e2f6913-42f2-3578-28ed-567f6a4bdda1@xxxxxxxxxxx/ > > The implementation of O_MAYEXEC almost duplicates what execve(2) and > uselib(2) are already doing: setting MAY_OPENEXEC in acc_mode (which can > then be checked as MAY_EXEC, if enforced). > > This is an updated subset of the patch initially written by Vincent > Strubel for CLIP OS 4: > https://github.com/clipos-archive/src_platform_clip-patches/blob/f5cb330d6b684752e403b4e41b39f7004d88e561/1901_open_mayexec.patch > This patch has been used for more than 12 years with customized script > interpreters. Some examples (with the original O_MAYEXEC) can be found > here: > https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC > > Co-developed-by: Vincent Strubel <vincent.strubel@xxxxxxxxxxx> > Signed-off-by: Vincent Strubel <vincent.strubel@xxxxxxxxxxx> Acked-by: Kees Cook <keescook@xxxxxxxxxxxx> -- Kees Cook
