Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Jul 2020 12:03:01 -0700
From: Kees Cook <>
To: Mickaël Salaün <>
Cc:, Aleksa Sarai <>,
	Alexei Starovoitov <>,
	Al Viro <>,
	Andrew Morton <>,
	Andy Lutomirski <>,
	Christian Brauner <>,
	Christian Heimes <>,
	Daniel Borkmann <>,
	Deven Bowers <>,
	Dmitry Vyukov <>,
	Eric Biggers <>,
	Eric Chiang <>,
	Florian Weimer <>,
	James Morris <>, Jan Kara <>,
	Jann Horn <>, Jonathan Corbet <>,
	Lakshmi Ramasubramanian <>,
	Matthew Garrett <>,
	Matthew Wilcox <>,
	Michael Kerrisk <>,
	Mimi Zohar <>,
	Philippe Trébuchet <>,
	Scott Shell <>,
	Sean Christopherson <>,
	Shuah Khan <>, Steve Dower <>,
	Steve Grubb <>,
	Tetsuo Handa <>,
	Thibaut Sautereau <>,
	Vincent Strubel <>,,,,,,
	Thibaut Sautereau <>
Subject: Re: [PATCH v7 4/7] fs: Introduce O_MAYEXEC flag for openat2(2)

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:
> 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:
> 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:
> Co-developed-by: Vincent Strubel <>
> Signed-off-by: Vincent Strubel <>

Acked-by: Kees Cook <>

Kees Cook

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.