Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Jan Kara <jack@suse.cz>
Date: 2018-12-12 14:43:10
Also in:
linux-api, linux-security-module, lkml
On Wed 12-12-18 09:17:08, Micka�l Sala�n wrote:
When the O_MAYEXEC flag is passed, sys_open() may be subject to additional restrictions depending on a security policy implemented by an LSM through the inode_permission hook. 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 (for which the kernel can't help): command line parameters (e.g., option -e for Perl), module loading (e.g., option -m for Python), stdin, file sourcing, environment variables, configuration files... 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. A simple security policy implementation is available in a following patch for Yama. This is an updated subset of the patch initially written by Vincent Strubel for CLIP OS: https://github.com/clipos-archive/src_platform_clip-patches/blob/f5cb330d6b684752e403b4e41b39f7004d88e561/1901_open_mayexec.patch This patch has been used for more than 10 years with customized script interpreters. Some examples can be found here: https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC Signed-off-by: Micka�l Sala�n <mic@digikod.net> Signed-off-by: Thibaut Sautereau <redacted> Signed-off-by: Vincent Strubel <redacted> Reviewed-by: Philippe Tr�buchet <redacted> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Kees Cook <redacted> Cc: Micka�l Sala�n <redacted>
...
quoted hunk ↗ jump to hunk
diff --git a/fs/open.c b/fs/open.c index 0285ce7dbd51..75479b79a58f 100644 --- a/fs/open.c +++ b/fs/open.c@@ -974,6 +974,10 @@ static inline int build_open_flags(int flags, umode_t mode, struct open_flags *o if (flags & O_APPEND) acc_mode |= MAY_APPEND; + /* Check execution permissions on open. */ + if (flags & O_MAYEXEC) + acc_mode |= MAY_OPENEXEC; + op->acc_mode = acc_mode; op->intent = flags & O_PATH ? 0 : LOOKUP_OPEN;
I don't feel experienced enough in security to tell whether we want this functionality or not. But if we do this, shouldn't we also set FMODE_EXEC on the resulting struct file? That way also security_file_open() can be used to arbitrate such executable opens and in particular fanotify permission event FAN_OPEN_EXEC will get properly generated which I guess is desirable (support for it is sitting in my tree waiting for the merge window) - adding some audit people involved in FAN_OPEN_EXEC to CC. Just an idea... Honza -- Jan Kara [off-list ref] SUSE Labs, CR