linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/5] Add support for O_MAYEXEC
@ 2019-09-06 15:24 Mickaël Salaün
  2019-09-06 15:24 ` [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Mickaël Salaün
                   ` (6 more replies)
  0 siblings, 7 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-06 15:24 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mickaël Salaün, Aleksa Sarai, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Florian Weimer, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

Hi,

The goal of this patch series is to control script interpretation.  A
new O_MAYEXEC flag used by sys_open() is added to enable userspace
script interpreter to delegate to the kernel (and thus the system
security policy) the permission to interpret/execute scripts or other
files containing what can be seen as commands.

This second series mainly differ from the previous one [1] by moving the
basic security policy from Yama to the filesystem subsystem.  This
policy can be enforced by the system administrator through a sysctl
configuration consistent with the mount points.

Furthermore, the security policy can also be delegated to an LSM, either
a MAC system or an integrity system.  For instance, the new kernel
MAY_OPENEXEC flag closes a major IMA measurement/appraisal interpreter
integrity gap by bringing the ability to check the use of scripts [2].
Other uses are expected, such as for openat2(2) [3], SGX integration
[4], and bpffs [5].

Userspace need to adapt to take advantage of this new feature.  For
example, the PEP 578 [6] (Runtime Audit Hooks) enables Python 3.8 to be
extended with policy enforcement points related to code interpretation,
which can be used to align with the PowerShell audit features.
Additional Python security improvements (e.g. a limited interpreter
withou -c, stdin piping of code) are on their way.

The initial idea come from CLIP OS and the original implementation has
been used for more than 10 years:
https://github.com/clipos-archive/clipos4_doc

An introduction to O_MAYEXEC was given at the Linux Security Summit
Europe 2018 - Linux Kernel Security Contributions by ANSSI:
https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s
The "write xor execute" principle was explained at Kernel Recipes 2018 -
CLIP OS: a defense-in-depth OS:
https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s

This patch series can be applied on top of v5.3-rc7.  This can be tested
with CONFIG_SYSCTL.  I would really appreciate constructive comments on
this patch series.


# Changes since v1

* move code from Yama to the FS subsystem
* set __FMODE_EXEC when using O_MAYEXEC to make this information
  available through the new fanotify/FAN_OPEN_EXEC event
* only match regular files (not directories nor other types), which
  follows the same semantic as commit 73601ea5b7b1 ("fs/open.c: allow
  opening only regular files during execve()")
* improve tests

[1] https://lore.kernel.org/lkml/20181212081712.32347-1-mic@digikod.net/
[2] https://lore.kernel.org/lkml/1544647356.4028.105.camel@linux.ibm.com/
[3] https://lore.kernel.org/lkml/20190904201933.10736-6-cyphar@cyphar.com/
[4] https://lore.kernel.org/lkml/CALCETrVovr8XNZSroey7pHF46O=kj_c5D9K8h=z2T_cNrpvMig@mail.gmail.com/
[5] https://lore.kernel.org/lkml/CALCETrVeZ0eufFXwfhtaG_j+AdvbzEWE0M3wjXMWVEO7pj+xkw@mail.gmail.com/
[6] https://www.python.org/dev/peps/pep-0578/

Regards,

Mickaël Salaün (5):
  fs: Add support for an O_MAYEXEC flag on sys_open()
  fs: Add a MAY_EXECMOUNT flag to infer the noexec mount propertie
  fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC
  selftest/exec: Add tests for O_MAYEXEC enforcing
  doc: Add documentation for the fs.open_mayexec_enforce sysctl

 Documentation/admin-guide/sysctl/fs.rst     |  43 +++
 fs/fcntl.c                                  |   2 +-
 fs/namei.c                                  |  70 +++++
 fs/open.c                                   |   6 +
 include/linux/fcntl.h                       |   2 +-
 include/linux/fs.h                          |   7 +
 include/uapi/asm-generic/fcntl.h            |   3 +
 kernel/sysctl.c                             |   7 +
 tools/testing/selftests/exec/.gitignore     |   1 +
 tools/testing/selftests/exec/Makefile       |   4 +-
 tools/testing/selftests/exec/omayexec.c     | 317 ++++++++++++++++++++
 tools/testing/selftests/kselftest_harness.h |   3 +
 12 files changed, 462 insertions(+), 3 deletions(-)
 create mode 100644 tools/testing/selftests/exec/omayexec.c

-- 
2.23.0


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 15:24 [PATCH v2 0/5] Add support for O_MAYEXEC Mickaël Salaün
@ 2019-09-06 15:24 ` Mickaël Salaün
  2019-09-06 15:56   ` Florian Weimer
  2019-09-06 15:24 ` [PATCH v2 2/5] fs: Add a MAY_EXECMOUNT flag to infer the noexec mount propertie Mickaël Salaün
                   ` (5 subsequent siblings)
  6 siblings, 1 reply; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-06 15:24 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mickaël Salaün, Aleksa Sarai, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Florian Weimer, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

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

Changes since v1:
* set __FMODE_EXEC when using O_MAYEXEC to make this information
  available through the new fanotify/FAN_OPEN_EXEC event (suggested by
  Jan Kara and Matthew Bobrowski)

Signed-off-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
Signed-off-by: Vincent Strubel <vincent.strubel@ssi.gouv.fr>
Reviewed-by: Philippe Trébuchet <philippe.trebuchet@ssi.gouv.fr>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <keescook@chromium.org>
Cc: Mickaël Salaün <mickael.salaun@ssi.gouv.fr>
---
 fs/fcntl.c                       | 2 +-
 fs/open.c                        | 6 ++++++
 include/linux/fcntl.h            | 2 +-
 include/linux/fs.h               | 2 ++
 include/uapi/asm-generic/fcntl.h | 3 +++
 5 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/fs/fcntl.c b/fs/fcntl.c
index 3d40771e8e7c..4cf05a2fd162 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -1031,7 +1031,7 @@ static int __init fcntl_init(void)
 	 * Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
 	 * is defined as O_NONBLOCK on some platforms and not on others.
 	 */
-	BUILD_BUG_ON(21 - 1 /* for O_RDONLY being 0 */ !=
+	BUILD_BUG_ON(22 - 1 /* for O_RDONLY being 0 */ !=
 		HWEIGHT32(
 			(VALID_OPEN_FLAGS & ~(O_NONBLOCK | O_NDELAY)) |
 			__FMODE_EXEC | __FMODE_NONOTIFY));
diff --git a/fs/open.c b/fs/open.c
index a59abe3c669a..1b9b6fedf7cd 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -989,6 +989,12 @@ static inline int build_open_flags(int flags, umode_t mode, struct open_flags *o
 		acc_mode = 0;
 	}
 
+	/* Check execution permissions on open. */
+	if (flags & O_MAYEXEC) {
+		acc_mode |= MAY_OPENEXEC;
+		flags |= __FMODE_EXEC;
+	}
+
 	op->open_flag = flags;
 
 	/* O_TRUNC implies we need access checks for write permissions */
diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
index d019df946cb2..af88fb6c8313 100644
--- a/include/linux/fcntl.h
+++ b/include/linux/fcntl.h
@@ -9,7 +9,7 @@
 	(O_RDONLY | O_WRONLY | O_RDWR | O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC | \
 	 O_APPEND | O_NDELAY | O_NONBLOCK | O_NDELAY | __O_SYNC | O_DSYNC | \
 	 FASYNC	| O_DIRECT | O_LARGEFILE | O_DIRECTORY | O_NOFOLLOW | \
-	 O_NOATIME | O_CLOEXEC | O_PATH | __O_TMPFILE)
+	 O_NOATIME | O_CLOEXEC | O_PATH | __O_TMPFILE | O_MAYEXEC)
 
 #ifndef force_o_largefile
 #define force_o_largefile() (!IS_ENABLED(CONFIG_ARCH_32BIT_OFF_T))
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 997a530ff4e9..848f5711bdf0 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -99,6 +99,8 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
 #define MAY_CHDIR		0x00000040
 /* called from RCU mode, don't block */
 #define MAY_NOT_BLOCK		0x00000080
+/* the inode is opened with O_MAYEXEC */
+#define MAY_OPENEXEC		0x00000100
 
 /*
  * flags in file.f_mode.  Note that FMODE_READ and FMODE_WRITE must correspond
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 9dc0bf0c5a6e..cbb9425d6e7c 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -97,6 +97,9 @@
 #define O_NDELAY	O_NONBLOCK
 #endif
 
+/* command execution from file is intended, check exec permissions */
+#define O_MAYEXEC	040000000
+
 #define F_DUPFD		0	/* dup */
 #define F_GETFD		1	/* get close_on_exec */
 #define F_SETFD		2	/* set/clear close_on_exec */
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 45+ messages in thread

* [PATCH v2 2/5] fs: Add a MAY_EXECMOUNT flag to infer the noexec mount propertie
  2019-09-06 15:24 [PATCH v2 0/5] Add support for O_MAYEXEC Mickaël Salaün
  2019-09-06 15:24 ` [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Mickaël Salaün
@ 2019-09-06 15:24 ` Mickaël Salaün
  2019-09-06 15:24 ` [PATCH v2 3/5] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC Mickaël Salaün
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-06 15:24 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mickaël Salaün, Aleksa Sarai, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Florian Weimer, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

An LSM doesn't get path information related to an access request to open
an inode.  This new (internal) MAY_EXECMOUNT flag enables an LSM to
check if the underlying mount point of an inode is marked as executable.
This is useful to implement a security policy taking advantage of the
noexec mount option.

This flag is set according to path_noexec(), which checks if a mount
point is mounted with MNT_NOEXEC or if the underlying superblock is
SB_I_NOEXEC.

Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Philippe Trébuchet <philippe.trebuchet@ssi.gouv.fr>
Reviewed-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <keescook@chromium.org>
Cc: Mickaël Salaün <mickael.salaun@ssi.gouv.fr>
---
 fs/namei.c         | 2 ++
 include/linux/fs.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/fs/namei.c b/fs/namei.c
index 209c51a5226c..0a6b9483d0cb 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2968,6 +2968,8 @@ static int may_open(const struct path *path, int acc_mode, int flag)
 		break;
 	}
 
+	/* Pass the mount point executability. */
+	acc_mode |= path_noexec(path) ? 0 : MAY_EXECMOUNT;
 	error = inode_permission(inode, MAY_OPEN | acc_mode);
 	if (error)
 		return error;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 848f5711bdf0..e57609dac8dd 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -101,6 +101,8 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
 #define MAY_NOT_BLOCK		0x00000080
 /* the inode is opened with O_MAYEXEC */
 #define MAY_OPENEXEC		0x00000100
+/* the mount point is marked as executable */
+#define MAY_EXECMOUNT		0x00000200
 
 /*
  * flags in file.f_mode.  Note that FMODE_READ and FMODE_WRITE must correspond
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 45+ messages in thread

* [PATCH v2 3/5] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC
  2019-09-06 15:24 [PATCH v2 0/5] Add support for O_MAYEXEC Mickaël Salaün
  2019-09-06 15:24 ` [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Mickaël Salaün
  2019-09-06 15:24 ` [PATCH v2 2/5] fs: Add a MAY_EXECMOUNT flag to infer the noexec mount propertie Mickaël Salaün
@ 2019-09-06 15:24 ` Mickaël Salaün
  2019-09-06 15:24 ` [PATCH v2 4/5] selftest/exec: Add tests for O_MAYEXEC enforcing Mickaël Salaün
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-06 15:24 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mickaël Salaün, Aleksa Sarai, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Florian Weimer, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

Enable to either propagate the mount options from the underlying VFS
mount to prevent execution, or to propagate the file execute permission.
This may allow a script interpreter to check execution permissions
before reading commands from a file.

The main goal is to be able 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).

Add a new sysctl fs.open_mayexec_enforce to control this behavior.  A
following patch adds documentation.

Changes since v1:
* move code from Yama to the FS subsystem (suggested by Kees Cook)
* make omayexec_inode_permission() static (suggested by Jann Horn)
* use mode 0600 for the sysctl
* only match regular files (not directories nor other types), which
  follows the same semantic as commit 73601ea5b7b1 ("fs/open.c: allow
  opening only regular files during execve()")

Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Philippe Trébuchet <philippe.trebuchet@ssi.gouv.fr>
Reviewed-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <keescook@chromium.org>
Cc: Mickaël Salaün <mickael.salaun@ssi.gouv.fr>
---
 fs/namei.c         | 68 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/fs.h |  3 ++
 kernel/sysctl.c    |  7 +++++
 3 files changed, 78 insertions(+)

diff --git a/fs/namei.c b/fs/namei.c
index 0a6b9483d0cb..abd29a76ecef 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -39,6 +39,7 @@
 #include <linux/bitops.h>
 #include <linux/init_task.h>
 #include <linux/uaccess.h>
+#include <linux/sysctl.h>
 
 #include "internal.h"
 #include "mount.h"
@@ -411,6 +412,34 @@ static int sb_permission(struct super_block *sb, struct inode *inode, int mask)
 	return 0;
 }
 
+#define OMAYEXEC_ENFORCE_NONE	0
+#define OMAYEXEC_ENFORCE_MOUNT	(1 << 0)
+#define OMAYEXEC_ENFORCE_FILE	(1 << 1)
+#define _OMAYEXEC_LAST		OMAYEXEC_ENFORCE_FILE
+#define _OMAYEXEC_MASK		((_OMAYEXEC_LAST << 1) - 1)
+
+/**
+ * omayexec_inode_permission - check O_MAYEXEC before accessing an inode
+ * @inode: inode structure to check
+ * @mask: permission mask
+ *
+ * Return 0 if access is permitted, -EACCES otherwise.
+ */
+static int omayexec_inode_permission(struct inode *inode, int mask)
+{
+	if (!(mask & MAY_OPENEXEC))
+		return 0;
+
+	if ((sysctl_omayexec_enforce & OMAYEXEC_ENFORCE_MOUNT) &&
+			!(mask & MAY_EXECMOUNT))
+		return -EACCES;
+
+	if (sysctl_omayexec_enforce & OMAYEXEC_ENFORCE_FILE)
+		return generic_permission(inode, MAY_EXEC);
+
+	return 0;
+}
+
 /**
  * inode_permission - Check for access rights to a given inode
  * @inode: Inode to check permission on
@@ -454,10 +483,48 @@ int inode_permission(struct inode *inode, int mask)
 	if (retval)
 		return retval;
 
+	retval = omayexec_inode_permission(inode, mask);
+	if (retval)
+		return retval;
+
 	return security_inode_permission(inode, mask);
 }
 EXPORT_SYMBOL(inode_permission);
 
+/*
+ * Handle open_mayexec_enforce sysctl
+ */
+#ifdef CONFIG_SYSCTL
+int proc_omayexec(struct ctl_table *table, int write, void __user *buffer,
+		size_t *lenp, loff_t *ppos)
+{
+	int error;
+
+	if (write) {
+		struct ctl_table table_copy;
+		int tmp_mayexec_enforce;
+
+		if (!capable(CAP_MAC_ADMIN))
+			return -EPERM;
+		tmp_mayexec_enforce = *((int *)table->data);
+		table_copy = *table;
+		/* do not erase sysctl_omayexec_enforce */
+		table_copy.data = &tmp_mayexec_enforce;
+		error = proc_dointvec(&table_copy, write, buffer, lenp, ppos);
+		if (error)
+			return error;
+		if ((tmp_mayexec_enforce | _OMAYEXEC_MASK) != _OMAYEXEC_MASK)
+			return -EINVAL;
+		*((int *)table->data) = tmp_mayexec_enforce;
+	} else {
+		error = proc_dointvec(table, write, buffer, lenp, ppos);
+		if (error)
+			return error;
+	}
+	return 0;
+}
+#endif
+
 /**
  * path_get - get a reference to a path
  * @path: path to get the reference to
@@ -887,6 +954,7 @@ int sysctl_protected_symlinks __read_mostly = 0;
 int sysctl_protected_hardlinks __read_mostly = 0;
 int sysctl_protected_fifos __read_mostly;
 int sysctl_protected_regular __read_mostly;
+int sysctl_omayexec_enforce __read_mostly = OMAYEXEC_ENFORCE_NONE;
 
 /**
  * may_follow_link - Check symlink following for unsafe situations
diff --git a/include/linux/fs.h b/include/linux/fs.h
index e57609dac8dd..735f5950cfed 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -81,6 +81,7 @@ extern int sysctl_protected_symlinks;
 extern int sysctl_protected_hardlinks;
 extern int sysctl_protected_fifos;
 extern int sysctl_protected_regular;
+extern int sysctl_omayexec_enforce;
 
 typedef __kernel_rwf_t rwf_t;
 
@@ -3452,6 +3453,8 @@ int proc_nr_dentry(struct ctl_table *table, int write,
 		  void __user *buffer, size_t *lenp, loff_t *ppos);
 int proc_nr_inodes(struct ctl_table *table, int write,
 		   void __user *buffer, size_t *lenp, loff_t *ppos);
+int proc_omayexec(struct ctl_table *table, int write, void __user *buffer,
+		size_t *lenp, loff_t *ppos);
 int __init get_filesystem_list(char *buf);
 
 #define __FMODE_EXEC		((__force int) FMODE_EXEC)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 078950d9605b..eaaeb229a828 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1911,6 +1911,13 @@ static struct ctl_table fs_table[] = {
 		.extra1		= SYSCTL_ZERO,
 		.extra2		= &two,
 	},
+	{
+		.procname       = "open_mayexec_enforce",
+		.data           = &sysctl_omayexec_enforce,
+		.maxlen         = sizeof(int),
+		.mode           = 0600,
+		.proc_handler   = proc_omayexec,
+	},
 #if defined(CONFIG_BINFMT_MISC) || defined(CONFIG_BINFMT_MISC_MODULE)
 	{
 		.procname	= "binfmt_misc",
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 45+ messages in thread

* [PATCH v2 4/5] selftest/exec: Add tests for O_MAYEXEC enforcing
  2019-09-06 15:24 [PATCH v2 0/5] Add support for O_MAYEXEC Mickaël Salaün
                   ` (2 preceding siblings ...)
  2019-09-06 15:24 ` [PATCH v2 3/5] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC Mickaël Salaün
@ 2019-09-06 15:24 ` Mickaël Salaün
  2019-09-06 15:24 ` [PATCH v2 5/5] doc: Add documentation for the fs.open_mayexec_enforce sysctl Mickaël Salaün
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-06 15:24 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mickaël Salaün, Aleksa Sarai, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Florian Weimer, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

Test propagation of noexec mount points or file executability through
files open with or without O_MAYEXEC.

Changes since v1:
* move tests from yama to exec
* fix _GNU_SOURCE in kselftest_harness.h
* add a new test sysctl_access_write to check if CAP_MAC_ADMIN is taken
  into account
* test directory execution which is always forbidden since commit
  73601ea5b7b1 ("fs/open.c: allow opening only regular files during
  execve()"), and also check that even the root user can not bypass file
  execution checks
* make sure delete_workspace() always as enough right to succeed
* cosmetic cleanup

Signed-off-by: Mickaël Salaün <mic@digikod.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Mickaël Salaün <mickael.salaun@ssi.gouv.fr>
Cc: Shuah Khan <shuah@kernel.org>
---
 tools/testing/selftests/exec/.gitignore     |   1 +
 tools/testing/selftests/exec/Makefile       |   4 +-
 tools/testing/selftests/exec/omayexec.c     | 317 ++++++++++++++++++++
 tools/testing/selftests/kselftest_harness.h |   3 +
 4 files changed, 324 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/exec/omayexec.c

diff --git a/tools/testing/selftests/exec/.gitignore b/tools/testing/selftests/exec/.gitignore
index b02279da6fa1..78487c987c07 100644
--- a/tools/testing/selftests/exec/.gitignore
+++ b/tools/testing/selftests/exec/.gitignore
@@ -1,3 +1,4 @@
+/omayexec
 subdir*
 script*
 execveat
diff --git a/tools/testing/selftests/exec/Makefile b/tools/testing/selftests/exec/Makefile
index 33339e31e365..a62b9ca306e7 100644
--- a/tools/testing/selftests/exec/Makefile
+++ b/tools/testing/selftests/exec/Makefile
@@ -3,7 +3,7 @@ CFLAGS = -Wall
 CFLAGS += -Wno-nonnull
 CFLAGS += -D_GNU_SOURCE
 
-TEST_GEN_PROGS := execveat
+TEST_GEN_PROGS := execveat omayexec
 TEST_GEN_FILES := execveat.symlink execveat.denatured script subdir
 # Makefile is a run-time dependency, since it's accessed by the execveat test
 TEST_FILES := Makefile
@@ -26,3 +26,5 @@ $(OUTPUT)/execveat.denatured: $(OUTPUT)/execveat
 	cp $< $@
 	chmod -x $@
 
+$(OUTPUT)/omayexec: omayexec.c ../kselftest_harness.h
+	$(CC) $(CFLAGS) -Wl,-no-as-needed $(LDFLAGS) -lcap $< -o $@
diff --git a/tools/testing/selftests/exec/omayexec.c b/tools/testing/selftests/exec/omayexec.c
new file mode 100644
index 000000000000..e4307b5a5417
--- /dev/null
+++ b/tools/testing/selftests/exec/omayexec.c
@@ -0,0 +1,317 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * O_MAYEXEC tests
+ *
+ * Copyright © 2018-2019 ANSSI
+ *
+ * Author: Mickaël Salaün <mic@digikod.net>
+ */
+
+#include <errno.h>
+#include <fcntl.h> /* O_CLOEXEC */
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h> /* strlen */
+#include <sys/capability.h>
+#include <sys/mount.h>
+#include <sys/stat.h> /* mkdir */
+#include <unistd.h> /* unlink, rmdir */
+
+#include "../kselftest_harness.h"
+
+#ifndef O_MAYEXEC
+#define O_MAYEXEC      040000000
+#endif
+
+#define SYSCTL_MAYEXEC	"/proc/sys/fs/open_mayexec_enforce"
+
+#define BIN_DIR		"./test-mount"
+#define BIN_PATH	BIN_DIR "/file"
+#define DIR_PATH	BIN_DIR "/directory"
+
+#define ALLOWED		1
+#define DENIED		0
+
+static void ignore_dac(struct __test_metadata *_metadata, int override)
+{
+	cap_t caps;
+	const cap_value_t cap_val[2] = {
+		CAP_DAC_OVERRIDE,
+		CAP_DAC_READ_SEARCH,
+	};
+
+	caps = cap_get_proc();
+	ASSERT_TRUE(!!caps);
+	ASSERT_FALSE(cap_set_flag(caps, CAP_EFFECTIVE, 2, cap_val,
+				override ? CAP_SET : CAP_CLEAR));
+	ASSERT_FALSE(cap_set_proc(caps));
+	EXPECT_FALSE(cap_free(caps));
+}
+
+static void ignore_mac(struct __test_metadata *_metadata, int override)
+{
+	cap_t caps;
+	const cap_value_t cap_val[1] = {
+		CAP_MAC_ADMIN,
+	};
+
+	caps = cap_get_proc();
+	ASSERT_TRUE(!!caps);
+	ASSERT_FALSE(cap_set_flag(caps, CAP_EFFECTIVE, 1, cap_val,
+				override ? CAP_SET : CAP_CLEAR));
+	ASSERT_FALSE(cap_set_proc(caps));
+	EXPECT_FALSE(cap_free(caps));
+}
+
+static void test_omx(struct __test_metadata *_metadata,
+		const char *const path, const int exec_allowed)
+{
+	int fd;
+
+	/* without O_MAYEXEC */
+	fd = open(path, O_RDONLY | O_CLOEXEC);
+	ASSERT_NE(-1, fd);
+	EXPECT_FALSE(close(fd));
+
+	/* with O_MAYEXEC */
+	fd = open(path, O_RDONLY | O_CLOEXEC | O_MAYEXEC);
+	if (exec_allowed) {
+		/* open should succeed */
+		ASSERT_NE(-1, fd);
+		EXPECT_FALSE(close(fd));
+	} else {
+		/* open should return EACCES */
+		ASSERT_EQ(-1, fd);
+		ASSERT_EQ(EACCES, errno);
+	}
+}
+
+static void test_omx_dir_file(struct __test_metadata *_metadata,
+		const char *const dir_path, const char *const file_path,
+		const int exec_allowed)
+{
+	/*
+	 * directory execution is always denied since commit 73601ea5b7b1
+	 * ("fs/open.c: allow opening only regular files during execve()")
+	 */
+	test_omx(_metadata, dir_path, DENIED);
+	test_omx(_metadata, file_path, exec_allowed);
+}
+
+static void test_dir_file(struct __test_metadata *_metadata,
+		const char *const dir_path, const char *const file_path,
+		const int exec_allowed)
+{
+	/* test as root */
+	ignore_dac(_metadata, 1);
+	test_omx_dir_file(_metadata, dir_path, file_path, exec_allowed);
+
+	/* test without bypass */
+	ignore_dac(_metadata, 0);
+	test_omx_dir_file(_metadata, dir_path, file_path, exec_allowed);
+}
+
+static void sysctl_write(struct __test_metadata *_metadata,
+		const char *path, const char *value)
+{
+	int fd;
+	size_t len_value;
+	ssize_t len_wrote;
+
+	fd = open(path, O_WRONLY | O_CLOEXEC);
+	ASSERT_NE(-1, fd);
+	len_value = strlen(value);
+	len_wrote = write(fd, value, len_value);
+	ASSERT_EQ(len_wrote, len_value);
+	EXPECT_FALSE(close(fd));
+}
+
+static void create_workspace(struct __test_metadata *_metadata,
+		int mount_exec, int file_exec)
+{
+	int fd;
+
+	/*
+	 * Cleanup previous workspace if any error previously happened (don't
+	 * check errors).
+	 */
+	umount(BIN_DIR);
+	rmdir(BIN_DIR);
+
+	/* create a clean mount point */
+	ASSERT_FALSE(mkdir(BIN_DIR, 00700));
+	ASSERT_FALSE(mount("test", BIN_DIR, "tmpfs",
+				MS_MGC_VAL | (mount_exec ? 0 : MS_NOEXEC),
+				"mode=0700,size=4k"));
+
+	/* create a test file */
+	fd = open(BIN_PATH, O_CREAT | O_RDONLY | O_CLOEXEC,
+			file_exec ? 00500 : 00400);
+	ASSERT_NE(-1, fd);
+	EXPECT_NE(-1, close(fd));
+
+	/* create a test directory */
+	ASSERT_FALSE(mkdir(DIR_PATH, file_exec ? 00500 : 00400));
+}
+
+static void delete_workspace(struct __test_metadata *_metadata)
+{
+	ignore_mac(_metadata, 1);
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "0");
+
+	/* no need to unlink BIN_PATH nor DIR_PATH */
+	ASSERT_FALSE(umount(BIN_DIR));
+	ASSERT_FALSE(rmdir(BIN_DIR));
+}
+
+FIXTURE_DATA(mount_exec_file_exec) { };
+
+FIXTURE_SETUP(mount_exec_file_exec)
+{
+	create_workspace(_metadata, 1, 1);
+}
+
+FIXTURE_TEARDOWN(mount_exec_file_exec)
+{
+	delete_workspace(_metadata);
+}
+
+TEST_F(mount_exec_file_exec, mount)
+{
+	/* enforce mount exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "1");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, ALLOWED);
+}
+
+TEST_F(mount_exec_file_exec, file)
+{
+	/* enforce file exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "2");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, ALLOWED);
+}
+
+TEST_F(mount_exec_file_exec, mount_file)
+{
+	/* enforce mount and file exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "3");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, ALLOWED);
+}
+
+FIXTURE_DATA(mount_exec_file_noexec) { };
+
+FIXTURE_SETUP(mount_exec_file_noexec)
+{
+	create_workspace(_metadata, 1, 0);
+}
+
+FIXTURE_TEARDOWN(mount_exec_file_noexec)
+{
+	delete_workspace(_metadata);
+}
+
+TEST_F(mount_exec_file_noexec, mount)
+{
+	/* enforce mount exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "1");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, ALLOWED);
+}
+
+TEST_F(mount_exec_file_noexec, file)
+{
+	/* enforce file exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "2");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, DENIED);
+}
+
+TEST_F(mount_exec_file_noexec, mount_file)
+{
+	/* enforce mount and file exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "3");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, DENIED);
+}
+
+FIXTURE_DATA(mount_noexec_file_exec) { };
+
+FIXTURE_SETUP(mount_noexec_file_exec)
+{
+	create_workspace(_metadata, 0, 1);
+}
+
+FIXTURE_TEARDOWN(mount_noexec_file_exec)
+{
+	delete_workspace(_metadata);
+}
+
+TEST_F(mount_noexec_file_exec, mount)
+{
+	/* enforce mount exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "1");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, DENIED);
+}
+
+TEST_F(mount_noexec_file_exec, file)
+{
+	/* enforce file exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "2");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, ALLOWED);
+}
+
+TEST_F(mount_noexec_file_exec, mount_file)
+{
+	/* enforce mount and file exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "3");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, DENIED);
+}
+
+FIXTURE_DATA(mount_noexec_file_noexec) { };
+
+FIXTURE_SETUP(mount_noexec_file_noexec)
+{
+	create_workspace(_metadata, 0, 0);
+}
+
+FIXTURE_TEARDOWN(mount_noexec_file_noexec)
+{
+	delete_workspace(_metadata);
+}
+
+TEST_F(mount_noexec_file_noexec, mount)
+{
+	/* enforce mount exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "1");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, DENIED);
+}
+
+TEST_F(mount_noexec_file_noexec, file)
+{
+	/* enforce file exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "2");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, DENIED);
+}
+
+TEST_F(mount_noexec_file_noexec, mount_file)
+{
+	/* enforce mount and file exec check */
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "3");
+	test_dir_file(_metadata, DIR_PATH, BIN_PATH, DENIED);
+}
+
+TEST(sysctl_access_write)
+{
+	int fd;
+	ssize_t len_wrote;
+
+	ignore_mac(_metadata, 1);
+	sysctl_write(_metadata, SYSCTL_MAYEXEC, "0");
+
+	ignore_mac(_metadata, 0);
+	fd = open(SYSCTL_MAYEXEC, O_WRONLY | O_CLOEXEC);
+	ASSERT_NE(-1, fd);
+	len_wrote = write(fd, "0", 1);
+	ASSERT_EQ(len_wrote, -1);
+	EXPECT_FALSE(close(fd));
+
+	ignore_mac(_metadata, 1);
+}
+
+TEST_HARNESS_MAIN
diff --git a/tools/testing/selftests/kselftest_harness.h b/tools/testing/selftests/kselftest_harness.h
index 5336b26506ab..6ae816fa2f62 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -50,7 +50,10 @@
 #ifndef __KSELFTEST_HARNESS_H
 #define __KSELFTEST_HARNESS_H
 
+#ifndef _GNU_SOURCE
 #define _GNU_SOURCE
+#endif
+
 #include <asm/types.h>
 #include <errno.h>
 #include <stdbool.h>
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 45+ messages in thread

* [PATCH v2 5/5] doc: Add documentation for the fs.open_mayexec_enforce sysctl
  2019-09-06 15:24 [PATCH v2 0/5] Add support for O_MAYEXEC Mickaël Salaün
                   ` (3 preceding siblings ...)
  2019-09-06 15:24 ` [PATCH v2 4/5] selftest/exec: Add tests for O_MAYEXEC enforcing Mickaël Salaün
@ 2019-09-06 15:24 ` Mickaël Salaün
  2019-09-06 18:50 ` [PATCH v2 0/5] Add support for O_MAYEXEC Steve Grubb
  2019-09-09  0:16 ` James Morris
  6 siblings, 0 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-06 15:24 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mickaël Salaün, Aleksa Sarai, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Florian Weimer, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

Changes since v1:
* move from LSM/Yama to sysctl/fs

Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Philippe Trébuchet <philippe.trebuchet@ssi.gouv.fr>
Reviewed-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Mickaël Salaün <mickael.salaun@ssi.gouv.fr>
---
 Documentation/admin-guide/sysctl/fs.rst | 43 +++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst
index 2a45119e3331..f2f5bbe428d6 100644
--- a/Documentation/admin-guide/sysctl/fs.rst
+++ b/Documentation/admin-guide/sysctl/fs.rst
@@ -37,6 +37,7 @@ Currently, these files are in /proc/sys/fs:
 - inode-nr
 - inode-state
 - nr_open
+- open_mayexec_enforce
 - overflowuid
 - overflowgid
 - pipe-user-pages-hard
@@ -165,6 +166,48 @@ system needs to prune the inode list instead of allocating
 more.
 
 
+open_mayexec_enforce
+--------------------
+
+The ``O_MAYEXEC`` flag can be passed to :manpage:`open(2)` to only open regular
+files that are expected to be executable.  If the file is not identified as
+executable, then the syscall returns -EACCES.  This may allow a script
+interpreter to check executable permission before reading commands from a file.
+One interesting use case is to enforce a "write xor execute" policy through
+interpreters.
+
+Thanks to this flag, it is possible to enforce the ``noexec`` mount option
+(i.e.  the underlying mount point of the file is mounted with MNT_NOEXEC or its
+underlying superblock is SB_I_NOEXEC) not only on ELF binaries but also on
+scripts.  This may be possible thanks to script interpreters using the
+``O_MAYEXEC`` flag.  The executable permission is then checked before reading
+commands from a file, and thus can enforce the ``noexec`` at the interpreter
+level by propagating this security policy to the scripts.  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.
+
+There is two complementary security policies: enforce the ``noexec`` mount
+option, or enforce executable file permission.  These policies are handled by
+the ``fs.open_mayexec_enforce`` sysctl (writable only with ``CAP_MAC_ADMIN``)
+as a bitmask:
+
+1 - mount restriction:
+    check that the mount options for the underlying VFS mount do not prevent
+    execution.
+
+2 - file permission restriction:
+    check that the to-be-opened file is marked as executable for the current
+    process (e.g., POSIX permissions).
+
+Code samples can be found in tools/testing/selftests/exec/omayexec.c and
+https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC .
+
+
 overflowgid & overflowuid
 -------------------------
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 15:24 ` [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Mickaël Salaün
@ 2019-09-06 15:56   ` Florian Weimer
  2019-09-06 16:06     ` Mickaël Salaün
  0 siblings, 1 reply; 45+ messages in thread
From: Florian Weimer @ 2019-09-06 15:56 UTC (permalink / raw)
  To: Mickaël Salaün
  Cc: linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	James Morris, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mickaël Salaün, Mimi Zohar, Philippe Trébuchet,
	Scott Shell, Sean Christopherson, Shuah Khan, Song Liu,
	Steve Dower, Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

Let's assume I want to add support for this to the glibc dynamic loader,
while still being able to run on older kernels.

Is it safe to try the open call first, with O_MAYEXEC, and if that fails
with EINVAL, try again without O_MAYEXEC?

Or do I risk disabling this security feature if I do that?

Do we need a different way for recognizing kernel support.  (Note that
we cannot probe paths in /proc for various reasons.)

Thanks,
Florian

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 15:56   ` Florian Weimer
@ 2019-09-06 16:06     ` Mickaël Salaün
  2019-09-06 16:48       ` Jeff Layton
  2019-09-06 17:07       ` Aleksa Sarai
  0 siblings, 2 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-06 16:06 UTC (permalink / raw)
  To: Florian Weimer, Mickaël Salaün
  Cc: linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	James Morris, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel


On 06/09/2019 17:56, Florian Weimer wrote:
> Let's assume I want to add support for this to the glibc dynamic loader,
> while still being able to run on older kernels.
>
> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> with EINVAL, try again without O_MAYEXEC?

The kernel ignore unknown open(2) flags, so yes, it is safe even for
older kernel to use O_MAYEXEC.

>
> Or do I risk disabling this security feature if I do that?

It is only a security feature if the kernel support it, otherwise it is
a no-op.

>
> Do we need a different way for recognizing kernel support.  (Note that
> we cannot probe paths in /proc for various reasons.)

There is no need to probe for kernel support.

>
> Thanks,
> Florian
>

--
Mickaël Salaün

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 16:06     ` Mickaël Salaün
@ 2019-09-06 16:48       ` Jeff Layton
  2019-09-06 17:13         ` Aleksa Sarai
  2019-09-06 17:14         ` Mickaël Salaün
  2019-09-06 17:07       ` Aleksa Sarai
  1 sibling, 2 replies; 45+ messages in thread
From: Jeff Layton @ 2019-09-06 16:48 UTC (permalink / raw)
  To: Mickaël Salaün, Florian Weimer, Mickaël Salaün
  Cc: linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	James Morris, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> On 06/09/2019 17:56, Florian Weimer wrote:
> > Let's assume I want to add support for this to the glibc dynamic loader,
> > while still being able to run on older kernels.
> > 
> > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > with EINVAL, try again without O_MAYEXEC?
> 
> The kernel ignore unknown open(2) flags, so yes, it is safe even for
> older kernel to use O_MAYEXEC.
> 

Well...maybe. What about existing programs that are sending down bogus
open flags? Once you turn this on, they may break...or provide a way to
circumvent the protections this gives.

Maybe this should be a new flag that is only usable in the new openat2()
syscall that's still under discussion? That syscall will enforce that
all flags are recognized. You presumably wouldn't need the sysctl if you
went that route too.

Anyone that wants to use this will have to recompile anyway. If the
kernel doesn't support openat2 or if the flag is rejected then you know
that you have no O_MAYEXEC support and can decide what to do.

> > Or do I risk disabling this security feature if I do that?
> 
> It is only a security feature if the kernel support it, otherwise it is
> a no-op.
> 

With a security feature, I think we really want userland to aware of
whether it works.

> > Do we need a different way for recognizing kernel support.  (Note that
> > we cannot probe paths in /proc for various reasons.)
> 
> There is no need to probe for kernel support.
> 
> > Thanks,
> > Florian
> > 
> 
> --
> Mickaël Salaün
> 
> Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 16:06     ` Mickaël Salaün
  2019-09-06 16:48       ` Jeff Layton
@ 2019-09-06 17:07       ` Aleksa Sarai
  2019-09-06 17:20         ` Christian Brauner
  1 sibling, 1 reply; 45+ messages in thread
From: Aleksa Sarai @ 2019-09-06 17:07 UTC (permalink / raw)
  To: Mickaël Salaün
  Cc: Florian Weimer, Mickaël Salaün, linux-kernel,
	Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
	Daniel Borkmann, Eric Chiang, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mimi Zohar, Philippe Trébuchet,
	Scott Shell, Sean Christopherson, Shuah Khan, Song Liu,
	Steve Dower, Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> 
> On 06/09/2019 17:56, Florian Weimer wrote:
> > Let's assume I want to add support for this to the glibc dynamic loader,
> > while still being able to run on older kernels.
> >
> > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > with EINVAL, try again without O_MAYEXEC?
> 
> The kernel ignore unknown open(2) flags, so yes, it is safe even for
> older kernel to use O_MAYEXEC.

Depends on your definition of "safe" -- a security feature that you will
silently not enable on older kernels doesn't sound super safe to me.
Unfortunately this is a limitation of open(2) that we cannot change --
which is why the openat2(2) proposal I've been posting gives -EINVAL for
unknown O_* flags.

There is a way to probe for support (though unpleasant), by creating a
test O_MAYEXEC fd and then checking if the flag is present in
/proc/self/fdinfo/$n.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 16:48       ` Jeff Layton
@ 2019-09-06 17:13         ` Aleksa Sarai
  2019-09-06 19:43           ` Jeff Layton
  2019-09-06 17:14         ` Mickaël Salaün
  1 sibling, 1 reply; 45+ messages in thread
From: Aleksa Sarai @ 2019-09-06 17:13 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > On 06/09/2019 17:56, Florian Weimer wrote:
> > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > while still being able to run on older kernels.
> > > 
> > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > > with EINVAL, try again without O_MAYEXEC?
> > 
> > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > older kernel to use O_MAYEXEC.
> > 
> 
> Well...maybe. What about existing programs that are sending down bogus
> open flags? Once you turn this on, they may break...or provide a way to
> circumvent the protections this gives.

It should be noted that this has been a valid concern for every new O_*
flag introduced (and yet we still introduced new flags, despite the
concern) -- though to be fair, O_TMPFILE actually does have a
work-around with the O_DIRECTORY mask setup.

The openat2() set adds O_EMPTYPATH -- though in fairness it's also
backwards compatible because empty path strings have always given ENOENT
(or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.

> Maybe this should be a new flag that is only usable in the new openat2()
> syscall that's still under discussion? That syscall will enforce that
> all flags are recognized. You presumably wouldn't need the sysctl if you
> went that route too.

I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
it, since I'd heard about this work through the grape-vine).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 16:48       ` Jeff Layton
  2019-09-06 17:13         ` Aleksa Sarai
@ 2019-09-06 17:14         ` Mickaël Salaün
  2019-09-06 18:38           ` Jeff Layton
  1 sibling, 1 reply; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-06 17:14 UTC (permalink / raw)
  To: Jeff Layton, Florian Weimer, Mickaël Salaün
  Cc: linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	James Morris, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel


On 06/09/2019 18:48, Jeff Layton wrote:
> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>> On 06/09/2019 17:56, Florian Weimer wrote:
>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>> while still being able to run on older kernels.
>>>
>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>>> with EINVAL, try again without O_MAYEXEC?
>>
>> The kernel ignore unknown open(2) flags, so yes, it is safe even for
>> older kernel to use O_MAYEXEC.
>>
>
> Well...maybe. What about existing programs that are sending down bogus
> open flags? Once you turn this on, they may break...or provide a way to
> circumvent the protections this gives.

Well, I don't think we should nor could care about bogus programs that
do not conform to the Linux ABI.

>
> Maybe this should be a new flag that is only usable in the new openat2()
> syscall that's still under discussion? That syscall will enforce that
> all flags are recognized. You presumably wouldn't need the sysctl if you
> went that route too.

Here is a thread about a new syscall:
https://lore.kernel.org/lkml/1544699060.6703.11.camel@linux.ibm.com/

I don't think it fit well with auditing nor integrity. Moreover using
the current open(2) behavior of ignoring unknown flags fit well with the
usage of O_MAYEXEC (because it is only a hint to the kernel about the
use of the *opened* file).

>
> Anyone that wants to use this will have to recompile anyway. If the
> kernel doesn't support openat2 or if the flag is rejected then you know
> that you have no O_MAYEXEC support and can decide what to do.

If we want to enforce a security policy, we need to either be the system
administrator or the distro developer. If a distro ship interpreters
using this flag, we don't need to recompile anything, but we need to be
able to control the enforcement according to the mount point
configuration (or an advanced MAC, or an IMA config). I don't see why an
userspace process should check if this flag is supported or not, it
should simply use it, and the sysadmin will enable an enforcement if it
makes sense for the whole system.

>
>>> Or do I risk disabling this security feature if I do that?
>>
>> It is only a security feature if the kernel support it, otherwise it is
>> a no-op.
>>
>
> With a security feature, I think we really want userland to aware of
> whether it works.

If userland would like to enforce something, it can already do it
without any kernel modification. The goal of the O_MAYEXEC flag is to
enable the kernel, hence sysadmins or system designers, to enforce a
global security policy that makes sense.

>
>>> Do we need a different way for recognizing kernel support.  (Note that
>>> we cannot probe paths in /proc for various reasons.)
>>
>> There is no need to probe for kernel support.
>>
>>> Thanks,
>>> Florian
>>>
Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 17:07       ` Aleksa Sarai
@ 2019-09-06 17:20         ` Christian Brauner
  2019-09-06 17:24           ` Mickaël Salaün
  2019-09-06 17:40           ` Tycho Andersen
  0 siblings, 2 replies; 45+ messages in thread
From: Christian Brauner @ 2019-09-06 17:20 UTC (permalink / raw)
  To: Aleksa Sarai
  Cc: Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
> On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> > 
> > On 06/09/2019 17:56, Florian Weimer wrote:
> > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > while still being able to run on older kernels.
> > >
> > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > > with EINVAL, try again without O_MAYEXEC?
> > 
> > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > older kernel to use O_MAYEXEC.
> 
> Depends on your definition of "safe" -- a security feature that you will
> silently not enable on older kernels doesn't sound super safe to me.
> Unfortunately this is a limitation of open(2) that we cannot change --
> which is why the openat2(2) proposal I've been posting gives -EINVAL for
> unknown O_* flags.
> 
> There is a way to probe for support (though unpleasant), by creating a
> test O_MAYEXEC fd and then checking if the flag is present in
> /proc/self/fdinfo/$n.

Which Florian said they can't do for various reasons.

It is a major painpoint if there's no easy way for userspace to probe
for support. Especially if it's security related which usually means
that you want to know whether this feature works or not.

Christian

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 17:20         ` Christian Brauner
@ 2019-09-06 17:24           ` Mickaël Salaün
  2019-09-06 17:40           ` Tycho Andersen
  1 sibling, 0 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-06 17:24 UTC (permalink / raw)
  To: Christian Brauner, Aleksa Sarai
  Cc: Florian Weimer, Mickaël Salaün, linux-kernel,
	Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
	Daniel Borkmann, Eric Chiang, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mimi Zohar, Philippe Trébuchet,
	Scott Shell, Sean Christopherson, Shuah Khan, Song Liu,
	Steve Dower, Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel


On 06/09/2019 19:20, Christian Brauner wrote:
> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
>> On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
>>>
>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>>> while still being able to run on older kernels.
>>>>
>>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>>>> with EINVAL, try again without O_MAYEXEC?
>>>
>>> The kernel ignore unknown open(2) flags, so yes, it is safe even for
>>> older kernel to use O_MAYEXEC.
>>
>> Depends on your definition of "safe" -- a security feature that you will
>> silently not enable on older kernels doesn't sound super safe to me.
>> Unfortunately this is a limitation of open(2) that we cannot change --
>> which is why the openat2(2) proposal I've been posting gives -EINVAL for
>> unknown O_* flags.
>>
>> There is a way to probe for support (though unpleasant), by creating a
>> test O_MAYEXEC fd and then checking if the flag is present in
>> /proc/self/fdinfo/$n.
>
> Which Florian said they can't do for various reasons.
>
> It is a major painpoint if there's no easy way for userspace to probe
> for support. Especially if it's security related which usually means
> that you want to know whether this feature works or not.

I used "safe" deliberately (not "secure" which didn't make sense in this
sentence). According to the threat model, if the kernel doesn't support
the feature, it should be ignored by userland. In this case, it fit well
with the current behavior of open(2). I agree that the openat2(2)
behavior handling flags is the good way to do it (whitelisting), but the
O_MAYEXEC flag should not change the userland behavior on its own,
because it depend on a global policy. Even being able to probe for
O_MAYEXEC support does not make sense because it would not be enough to
know the system policy (either this flag is enforced or not…).

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 17:20         ` Christian Brauner
  2019-09-06 17:24           ` Mickaël Salaün
@ 2019-09-06 17:40           ` Tycho Andersen
  2019-09-06 18:27             ` Florian Weimer
  1 sibling, 1 reply; 45+ messages in thread
From: Tycho Andersen @ 2019-09-06 17:40 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Aleksa Sarai, Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
> > On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> > > 
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > while still being able to run on older kernels.
> > > >
> > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > > > with EINVAL, try again without O_MAYEXEC?
> > > 
> > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > older kernel to use O_MAYEXEC.
> > 
> > Depends on your definition of "safe" -- a security feature that you will
> > silently not enable on older kernels doesn't sound super safe to me.
> > Unfortunately this is a limitation of open(2) that we cannot change --
> > which is why the openat2(2) proposal I've been posting gives -EINVAL for
> > unknown O_* flags.
> > 
> > There is a way to probe for support (though unpleasant), by creating a
> > test O_MAYEXEC fd and then checking if the flag is present in
> > /proc/self/fdinfo/$n.
> 
> Which Florian said they can't do for various reasons.
> 
> It is a major painpoint if there's no easy way for userspace to probe
> for support. Especially if it's security related which usually means
> that you want to know whether this feature works or not.

What about just trying to violate the policy via fexecve() instead of
looking around in /proc? Still ugly, though.

Tycho

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 17:40           ` Tycho Andersen
@ 2019-09-06 18:27             ` Florian Weimer
  2019-09-06 18:46               ` Tycho Andersen
  0 siblings, 1 reply; 45+ messages in thread
From: Florian Weimer @ 2019-09-06 18:27 UTC (permalink / raw)
  To: Tycho Andersen
  Cc: Christian Brauner, Aleksa Sarai, Mickaël Salaün,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

* Tycho Andersen:

> On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
>> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
>> > On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
>> > > 
>> > > On 06/09/2019 17:56, Florian Weimer wrote:
>> > > > Let's assume I want to add support for this to the glibc dynamic loader,
>> > > > while still being able to run on older kernels.
>> > > >
>> > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>> > > > with EINVAL, try again without O_MAYEXEC?
>> > > 
>> > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
>> > > older kernel to use O_MAYEXEC.
>> > 
>> > Depends on your definition of "safe" -- a security feature that you will
>> > silently not enable on older kernels doesn't sound super safe to me.
>> > Unfortunately this is a limitation of open(2) that we cannot change --
>> > which is why the openat2(2) proposal I've been posting gives -EINVAL for
>> > unknown O_* flags.
>> > 
>> > There is a way to probe for support (though unpleasant), by creating a
>> > test O_MAYEXEC fd and then checking if the flag is present in
>> > /proc/self/fdinfo/$n.
>> 
>> Which Florian said they can't do for various reasons.
>> 
>> It is a major painpoint if there's no easy way for userspace to probe
>> for support. Especially if it's security related which usually means
>> that you want to know whether this feature works or not.
>
> What about just trying to violate the policy via fexecve() instead of
> looking around in /proc? Still ugly, though.

How would we do this?  This is about opening the main executable as part
of an explicit loader invocation.  Typically, an fexecve will succeed
and try to run the program, but with the wrong dynamic loader.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 17:14         ` Mickaël Salaün
@ 2019-09-06 18:38           ` Jeff Layton
  2019-09-06 18:41             ` Andy Lutomirski
                               ` (2 more replies)
  0 siblings, 3 replies; 45+ messages in thread
From: Jeff Layton @ 2019-09-06 18:38 UTC (permalink / raw)
  To: Mickaël Salaün, Florian Weimer, Mickaël Salaün
  Cc: linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	James Morris, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
> On 06/09/2019 18:48, Jeff Layton wrote:
> > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > while still being able to run on older kernels.
> > > > 
> > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > > > with EINVAL, try again without O_MAYEXEC?
> > > 
> > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > older kernel to use O_MAYEXEC.
> > > 
> > 
> > Well...maybe. What about existing programs that are sending down bogus
> > open flags? Once you turn this on, they may break...or provide a way to
> > circumvent the protections this gives.
> 
> Well, I don't think we should nor could care about bogus programs that
> do not conform to the Linux ABI.
> 

But they do conform. The ABI is just undefined here. Unknown flags are
ignored so we never really know if $random_program may be setting them.

> > Maybe this should be a new flag that is only usable in the new openat2()
> > syscall that's still under discussion? That syscall will enforce that
> > all flags are recognized. You presumably wouldn't need the sysctl if you
> > went that route too.
> 
> Here is a thread about a new syscall:
> https://lore.kernel.org/lkml/1544699060.6703.11.camel@linux.ibm.com/
> 
> I don't think it fit well with auditing nor integrity. Moreover using
> the current open(2) behavior of ignoring unknown flags fit well with the
> usage of O_MAYEXEC (because it is only a hint to the kernel about the
> use of the *opened* file).
> 

The fact that open and openat didn't vet unknown flags is really a bug.

Too late to fix it now, of course, and as Aleksa points out, we've
worked around that in the past. Now though, we have a new openat2
syscall on the horizon. There's little need to continue these sorts of
hacks.

New open flags really have no place in the old syscalls, IMO.

> > Anyone that wants to use this will have to recompile anyway. If the
> > kernel doesn't support openat2 or if the flag is rejected then you know
> > that you have no O_MAYEXEC support and can decide what to do.
> 
> If we want to enforce a security policy, we need to either be the system
> administrator or the distro developer. If a distro ship interpreters
> using this flag, we don't need to recompile anything, but we need to be
> able to control the enforcement according to the mount point
> configuration (or an advanced MAC, or an IMA config). I don't see why an
> userspace process should check if this flag is supported or not, it
> should simply use it, and the sysadmin will enable an enforcement if it
> makes sense for the whole system.
> 

A userland program may need to do other risk mitigation if it sets
O_MAYEXEC and the kernel doesn't recognize it.

Personally, here's what I'd suggest:

- Base this on top of the openat2 set
- Change it that so that openat2() files are non-executable by default. Anyone wanting to do that needs to set O_MAYEXEC or upgrade the fd somehow.
- Only have the openat2 syscall pay attention to O_MAYEXEC. Let open and openat continue ignoring the new flag.

That works around a whole pile of potential ABI headaches. Note that
we'd need to make that decision before the openat2 patches are merged.

Even better would be to declare the new flag in some openat2-only flag
space, so there's no confusion about it being supported by legacy open
calls.

If glibc wants to implement an open -> openat2 wrapper in userland
later, it can set that flag in the wrapper implicitly to emulate the old
behavior.

Given that you're going to have to recompile software to take advantage
of this anyway, what's the benefit to changing legacy syscalls?

> > > > Or do I risk disabling this security feature if I do that?
> > > 
> > > It is only a security feature if the kernel support it, otherwise it is
> > > a no-op.
> > > 
> > 
> > With a security feature, I think we really want userland to aware of
> > whether it works.
> 
> If userland would like to enforce something, it can already do it
> without any kernel modification. The goal of the O_MAYEXEC flag is to
> enable the kernel, hence sysadmins or system designers, to enforce a
> global security policy that makes sense.
> 

I don't see how this helps anything if you can't tell whether the kernel
recognizes the damned thing. Also, our track record with global sysctl
switches like this is pretty poor. They're an administrative headache as
well as a potential attack vector.

I think your idea is a good one, but it could stand to have fewer moving
parts.
-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 18:38           ` Jeff Layton
@ 2019-09-06 18:41             ` Andy Lutomirski
  2019-09-09  9:18               ` Mickaël Salaün
  2019-09-06 18:44             ` Florian Weimer
  2019-09-06 19:03             ` James Morris
  2 siblings, 1 reply; 45+ messages in thread
From: Andy Lutomirski @ 2019-09-06 18:41 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Aleksa Sarai,
	Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
	Daniel Borkmann, Eric Chiang, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mimi Zohar, Philippe Trébuchet,
	Scott Shell, Sean Christopherson, Shuah Khan, Song Liu,
	Steve Dower, Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel



> On Sep 6, 2019, at 11:38 AM, Jeff Layton <jlayton@kernel.org> wrote:
> 
>> On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
>>> On 06/09/2019 18:48, Jeff Layton wrote:
>>>> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>>>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>>>> while still being able to run on older kernels.
>>>>> 
>>>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>>>>> with EINVAL, try again without O_MAYEXEC?
>>>> 
>>>> The kernel ignore unknown open(2) flags, so yes, it is safe even for
>>>> older kernel to use O_MAYEXEC.
>>>> 
>>> 
>>> Well...maybe. What about existing programs that are sending down bogus
>>> open flags? Once you turn this on, they may break...or provide a way to
>>> circumvent the protections this gives.
>> 
>> Well, I don't think we should nor could care about bogus programs that
>> do not conform to the Linux ABI.
>> 
> 
> But they do conform. The ABI is just undefined here. Unknown flags are
> ignored so we never really know if $random_program may be setting them.
> 
>>> Maybe this should be a new flag that is only usable in the new openat2()
>>> syscall that's still under discussion? That syscall will enforce that
>>> all flags are recognized. You presumably wouldn't need the sysctl if you
>>> went that route too.
>> 
>> Here is a thread about a new syscall:
>> https://lore.kernel.org/lkml/1544699060.6703.11.camel@linux.ibm.com/
>> 
>> I don't think it fit well with auditing nor integrity. Moreover using
>> the current open(2) behavior of ignoring unknown flags fit well with the
>> usage of O_MAYEXEC (because it is only a hint to the kernel about the
>> use of the *opened* file).
>> 
> 
> The fact that open and openat didn't vet unknown flags is really a bug.
> 
> Too late to fix it now, of course, and as Aleksa points out, we've
> worked around that in the past. Now though, we have a new openat2
> syscall on the horizon. There's little need to continue these sorts of
> hacks.
> 
> New open flags really have no place in the old syscalls, IMO.
> 
>>> Anyone that wants to use this will have to recompile anyway. If the
>>> kernel doesn't support openat2 or if the flag is rejected then you know
>>> that you have no O_MAYEXEC support and can decide what to do.
>> 
>> If we want to enforce a security policy, we need to either be the system
>> administrator or the distro developer. If a distro ship interpreters
>> using this flag, we don't need to recompile anything, but we need to be
>> able to control the enforcement according to the mount point
>> configuration (or an advanced MAC, or an IMA config). I don't see why an
>> userspace process should check if this flag is supported or not, it
>> should simply use it, and the sysadmin will enable an enforcement if it
>> makes sense for the whole system.
>> 
> 
> A userland program may need to do other risk mitigation if it sets
> O_MAYEXEC and the kernel doesn't recognize it.
> 
> Personally, here's what I'd suggest:
> 
> - Base this on top of the openat2 set
> - Change it that so that openat2() files are non-executable by default. Anyone wanting to do that needs to set O_MAYEXEC or upgrade the fd somehow.
> - Only have the openat2 syscall pay attention to O_MAYEXEC. Let open and openat continue ignoring the new flag.
> 
> That works around a whole pile of potential ABI headaches. Note that
> we'd need to make that decision before the openat2 patches are merged.
> 
> Even better would be to declare the new flag in some openat2-only flag
> space, so there's no confusion about it being supported by legacy open
> calls.
> 
> If glibc wants to implement an open -> openat2 wrapper in userland
> later, it can set that flag in the wrapper implicitly to emulate the old
> behavior.
> 
> Given that you're going to have to recompile software to take advantage
> of this anyway, what's the benefit to changing legacy syscalls?
> 
>>>>> Or do I risk disabling this security feature if I do that?
>>>> 
>>>> It is only a security feature if the kernel support it, otherwise it is
>>>> a no-op.
>>>> 
>>> 
>>> With a security feature, I think we really want userland to aware of
>>> whether it works.
>> 
>> If userland would like to enforce something, it can already do it
>> without any kernel modification. The goal of the O_MAYEXEC flag is to
>> enable the kernel, hence sysadmins or system designers, to enforce a
>> global security policy that makes sense.
>> 
> 
> I don't see how this helps anything if you can't tell whether the kernel
> recognizes the damned thing. Also, our track record with global sysctl
> switches like this is pretty poor. They're an administrative headache as
> well as a potential attack vector.

I tend to agree. The sysctl seems like it’s asking for trouble. I can see an ld.so.conf option to turn this thing off making sense.



^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 18:38           ` Jeff Layton
  2019-09-06 18:41             ` Andy Lutomirski
@ 2019-09-06 18:44             ` Florian Weimer
  2019-09-06 19:03             ` James Morris
  2 siblings, 0 replies; 45+ messages in thread
From: Florian Weimer @ 2019-09-06 18:44 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Mickaël Salaün, Mickaël Salaün, linux-kernel,
	Aleksa Sarai, Alexei Starovoitov, Al Viro, Andy Lutomirski,
	Christian Heimes, Daniel Borkmann, Eric Chiang, James Morris,
	Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
	Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

* Jeff Layton:

> Even better would be to declare the new flag in some openat2-only flag
> space, so there's no confusion about it being supported by legacy open
> calls.

Isn't that desirable anyway because otherwise fcntl with F_GETFL will
give really confusing results?

> If glibc wants to implement an open -> openat2 wrapper in userland
> later, it can set that flag in the wrapper implicitly to emulate the old
> behavior.

I see us rather doing the opposite, i.e. implement openat2 with
non-exotic flags using openat.  But we've bitten by this in the past, so
maybe that's not such a great idea.  It's tempting to make the same
mistake again for every new system call.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 18:27             ` Florian Weimer
@ 2019-09-06 18:46               ` Tycho Andersen
  0 siblings, 0 replies; 45+ messages in thread
From: Tycho Andersen @ 2019-09-06 18:46 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Christian Brauner, Aleksa Sarai, Mickaël Salaün,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

On Fri, Sep 06, 2019 at 08:27:31PM +0200, Florian Weimer wrote:
> * Tycho Andersen:
> 
> > On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
> >> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
> >> > On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> >> > > 
> >> > > On 06/09/2019 17:56, Florian Weimer wrote:
> >> > > > Let's assume I want to add support for this to the glibc dynamic loader,
> >> > > > while still being able to run on older kernels.
> >> > > >
> >> > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> >> > > > with EINVAL, try again without O_MAYEXEC?
> >> > > 
> >> > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> >> > > older kernel to use O_MAYEXEC.
> >> > 
> >> > Depends on your definition of "safe" -- a security feature that you will
> >> > silently not enable on older kernels doesn't sound super safe to me.
> >> > Unfortunately this is a limitation of open(2) that we cannot change --
> >> > which is why the openat2(2) proposal I've been posting gives -EINVAL for
> >> > unknown O_* flags.
> >> > 
> >> > There is a way to probe for support (though unpleasant), by creating a
> >> > test O_MAYEXEC fd and then checking if the flag is present in
> >> > /proc/self/fdinfo/$n.
> >> 
> >> Which Florian said they can't do for various reasons.
> >> 
> >> It is a major painpoint if there's no easy way for userspace to probe
> >> for support. Especially if it's security related which usually means
> >> that you want to know whether this feature works or not.
> >
> > What about just trying to violate the policy via fexecve() instead of
> > looking around in /proc? Still ugly, though.
> 
> How would we do this?  This is about opening the main executable as part
> of an explicit loader invocation.  Typically, an fexecve will succeed
> and try to run the program, but with the wrong dynamic loader.

Yeah, fexecve() was a think-o, sorry, you don't need to go that far. I
was thinking do what the tests in this series do: create a tmpfs with
MS_NOEXEC, put an executable file in it, and try and open it with
O_MAYEXEC. If that works, the kernel doesn't support the flag, and it
should give you -EACCES if the kernel does support the flag.

Still a lot of work, though. Seems better to just use openat2.

Tycho

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
  2019-09-06 15:24 [PATCH v2 0/5] Add support for O_MAYEXEC Mickaël Salaün
                   ` (4 preceding siblings ...)
  2019-09-06 15:24 ` [PATCH v2 5/5] doc: Add documentation for the fs.open_mayexec_enforce sysctl Mickaël Salaün
@ 2019-09-06 18:50 ` Steve Grubb
  2019-09-06 18:57   ` Florian Weimer
  2019-09-09  0:16 ` James Morris
  6 siblings, 1 reply; 45+ messages in thread
From: Steve Grubb @ 2019-09-06 18:50 UTC (permalink / raw)
  To: Mickaël Salaün
  Cc: linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	Florian Weimer, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Thibaut Sautereau,
	Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

On Friday, September 6, 2019 11:24:50 AM EDT Mickaël Salaün wrote:
> The goal of this patch series is to control script interpretation.  A
> new O_MAYEXEC flag used by sys_open() is added to enable userspace
> script interpreter to delegate to the kernel (and thus the system
> security policy) the permission to interpret/execute scripts or other
> files containing what can be seen as commands.

The problem is that this is only a gentleman's handshake. If I don't tell the
kernel that what I'm opening is tantamount to executing it, then the security
feature is never invoked. It is simple to strip the flags off of any system
call without needing privileges. For example:

#define _GNU_SOURCE
#include <link.h>
#include <fcntl.h>
#include <string.h>

unsigned int
la_version(unsigned int version)
{
    return version;
}

unsigned int
la_objopen(struct link_map *map, Lmid_t lmid, uintptr_t *cookie)
{
    return LA_FLG_BINDTO | LA_FLG_BINDFROM;
}

typedef int (*openat_t) (int dirfd, const char *pathname, int flags, mode_t mode);
static openat_t real_openat = 0L;
int my_openat(int dirfd, const char *pathname, int flags, mode_t mode)
{
        flags &= ~O_CLOEXEC;
        return real_openat(dirfd, pathname, flags, mode);
}

uintptr_t
la_symbind64(Elf64_Sym *sym, unsigned int ndx, uintptr_t *refcook,
        uintptr_t *defcook, unsigned int *flags, const char *symname)
{
    if (real_openat == 0L && strcmp(symname, "openat") == 0) {
        real_openat = (openat_t) sym->st_value;
        return (uintptr_t) my_openat;
    }
    return sym->st_value;
}

gcc -c -g -Wno-unused-parameter -W -Wall -Wundef -O2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fPIC  test.c
gcc -o strip-flags.so.0 -shared -Wl,-soname,strip-flags.so.0 -ldl test.o

Now, let's make a test program:

#include <stdio.h>
#include <dirent.h>
#include <fcntl.h>
#include <unistd.h>

int main(void)
{
        int dir_fd, fd;
        DIR *d = opendir("/etc");
        dir_fd = dirfd(d);
        fd = openat(dir_fd, "passwd", O_RDONLY|O_CLOEXEC);
        close (fd);
        closedir(d);
        return 0;
}

gcc -g -W -Wall -Wundef test.c -o test

OK, let's see what happens.
$ strace ./test 2>&1 | grep passwd
openat(3, "passwd", O_RDONLY|O_CLOEXEC) = 4

Now with LD_AUDIT
$ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test 2>&1 | grep passwd
openat(3, "passwd", O_RDONLY)           = 4

No O_CLOEXEC flag.

-Steve



^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
  2019-09-06 18:50 ` [PATCH v2 0/5] Add support for O_MAYEXEC Steve Grubb
@ 2019-09-06 18:57   ` Florian Weimer
  2019-09-06 19:07     ` Steve Grubb
  0 siblings, 1 reply; 45+ messages in thread
From: Florian Weimer @ 2019-09-06 18:57 UTC (permalink / raw)
  To: Steve Grubb
  Cc: Mickaël Salaün, linux-kernel, Aleksa Sarai,
	Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
	Daniel Borkmann, Eric Chiang, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Thibaut Sautereau,
	Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

* Steve Grubb:

> Now with LD_AUDIT
> $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test 2>&1 | grep passwd
> openat(3, "passwd", O_RDONLY)           = 4
>
> No O_CLOEXEC flag.

I think you need to explain in detail why you consider this a problem.

With LD_PRELOAD and LD_AUDIT, you can already do anything, including
scanning other loaded objects for a system call instruction and jumping
to that (in case a security module in the kernel performs a PC check to
confer additional privileges).

Thanks,
Florian

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 18:38           ` Jeff Layton
  2019-09-06 18:41             ` Andy Lutomirski
  2019-09-06 18:44             ` Florian Weimer
@ 2019-09-06 19:03             ` James Morris
  2019-09-09  9:25               ` Mickaël Salaün
  2 siblings, 1 reply; 45+ messages in thread
From: James Morris @ 2019-09-06 19:03 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Aleksa Sarai,
	Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
	Daniel Borkmann, Eric Chiang, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mimi Zohar, Philippe Trébuchet,
	Scott Shell, Sean Christopherson, Shuah Khan, Song Liu,
	Steve Dower, Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

On Fri, 6 Sep 2019, Jeff Layton wrote:

> The fact that open and openat didn't vet unknown flags is really a bug.
> 
> Too late to fix it now, of course, and as Aleksa points out, we've
> worked around that in the past. Now though, we have a new openat2
> syscall on the horizon. There's little need to continue these sorts of
> hacks.
> 
> New open flags really have no place in the old syscalls, IMO.

Agree here. It's unfortunate but a reality and Linus will reject any such 
changes which break existing userspace.


-- 
James Morris
<jmorris@namei.org>


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
  2019-09-06 18:57   ` Florian Weimer
@ 2019-09-06 19:07     ` Steve Grubb
  2019-09-06 19:26       ` Andy Lutomirski
  0 siblings, 1 reply; 45+ messages in thread
From: Steve Grubb @ 2019-09-06 19:07 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Mickaël Salaün, linux-kernel, Aleksa Sarai,
	Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
	Daniel Borkmann, Eric Chiang, James Morris, Jan Kara, Jann Horn,
	Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
	Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Thibaut S autereau,
	Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
> * Steve Grubb:
> > Now with LD_AUDIT
> > $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
> > 2>&1 | grep passwd openat(3, "passwd", O_RDONLY)           = 4
> > 
> > No O_CLOEXEC flag.
> 
> I think you need to explain in detail why you consider this a problem.

Because you can strip the O_MAYEXEC flag from being passed into the kernel. 
Once you do that, you defeat the security mechanism because it never gets 
invoked. The issue is that the only thing that knows _why_ something is being 
opened is user space. With this mechanism, you can attempt to pass this 
reason to the kernel so that it may see if policy permits this. But you can 
just remove the flag.

-Steve

> With LD_PRELOAD and LD_AUDIT, you can already do anything, including
> scanning other loaded objects for a system call instruction and jumping
> to that (in case a security module in the kernel performs a PC check to
> confer additional privileges).
> 
> Thanks,
> Florian





^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
  2019-09-06 19:07     ` Steve Grubb
@ 2019-09-06 19:26       ` Andy Lutomirski
  2019-09-06 22:44         ` Aleksa Sarai
  0 siblings, 1 reply; 45+ messages in thread
From: Andy Lutomirski @ 2019-09-06 19:26 UTC (permalink / raw)
  To: Steve Grubb
  Cc: Florian Weimer, Mickaël Salaün, linux-kernel,
	Aleksa Sarai, Alexei Starovoitov, Al Viro, Andy Lutomirski,
	Christian Heimes, Daniel Borkmann, Eric Chiang, James Morris,
	Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
	Matthew Wilcox, Michael Kerrisk, Mickaël Salaün,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Thibaut S autereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel



> On Sep 6, 2019, at 12:07 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> 
>> On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
>> * Steve Grubb:
>>> Now with LD_AUDIT
>>> $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
>>> 2>&1 | grep passwd openat(3, "passwd", O_RDONLY)           = 4
>>> 
>>> No O_CLOEXEC flag.
>> 
>> I think you need to explain in detail why you consider this a problem.
> 
> Because you can strip the O_MAYEXEC flag from being passed into the kernel. 
> Once you do that, you defeat the security mechanism because it never gets 
> invoked. The issue is that the only thing that knows _why_ something is being 
> opened is user space. With this mechanism, you can attempt to pass this 
> reason to the kernel so that it may see if policy permits this. But you can 
> just remove the flag.

I’m with Florian here. Once you are executing code in a process, you could just emulate some other unapproved code. This series is not intended to provide the kind of absolute protection you’re imagining.

What the kernel *could* do is prevent mmapping a non-FMODE_EXEC file with PROT_EXEC, which would indeed have a real effect (in an iOS-like world, for example) but would break many, many things.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 17:13         ` Aleksa Sarai
@ 2019-09-06 19:43           ` Jeff Layton
  2019-09-06 20:06             ` Andy Lutomirski
  2019-09-06 22:05             ` Aleksa Sarai
  0 siblings, 2 replies; 45+ messages in thread
From: Jeff Layton @ 2019-09-06 19:43 UTC (permalink / raw)
  To: Aleksa Sarai
  Cc: Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > while still being able to run on older kernels.
> > > > 
> > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > > > with EINVAL, try again without O_MAYEXEC?
> > > 
> > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > older kernel to use O_MAYEXEC.
> > > 
> > 
> > Well...maybe. What about existing programs that are sending down bogus
> > open flags? Once you turn this on, they may break...or provide a way to
> > circumvent the protections this gives.
> 
> It should be noted that this has been a valid concern for every new O_*
> flag introduced (and yet we still introduced new flags, despite the
> concern) -- though to be fair, O_TMPFILE actually does have a
> work-around with the O_DIRECTORY mask setup.
> 
> The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> backwards compatible because empty path strings have always given ENOENT
> (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> 
> > Maybe this should be a new flag that is only usable in the new openat2()
> > syscall that's still under discussion? That syscall will enforce that
> > all flags are recognized. You presumably wouldn't need the sysctl if you
> > went that route too.
> 
> I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> it, since I'd heard about this work through the grape-vine).
> 

I rather like the idea of having openat2 fds be non-executable by
default, and having userland request it specifically via O_MAYEXEC (or
some similar openat2 flag) if it's needed. Then you could add an
UPGRADE_EXEC flag instead?

That seems like something reasonable to do with a brand new API, and
might be very helpful for preventing certain classes of attacks.

-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 19:43           ` Jeff Layton
@ 2019-09-06 20:06             ` Andy Lutomirski
  2019-09-06 20:51               ` Jeff Layton
  2019-09-09  9:33               ` Mickaël Salaün
  2019-09-06 22:05             ` Aleksa Sarai
  1 sibling, 2 replies; 45+ messages in thread
From: Andy Lutomirski @ 2019-09-06 20:06 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Aleksa Sarai, Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel



> On Sep 6, 2019, at 12:43 PM, Jeff Layton <jlayton@kernel.org> wrote:
> 
>> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
>>> On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
>>>> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>>>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>>>> while still being able to run on older kernels.
>>>>> 
>>>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>>>>> with EINVAL, try again without O_MAYEXEC?
>>>> 
>>>> The kernel ignore unknown open(2) flags, so yes, it is safe even for
>>>> older kernel to use O_MAYEXEC.
>>>> 
>>> 
>>> Well...maybe. What about existing programs that are sending down bogus
>>> open flags? Once you turn this on, they may break...or provide a way to
>>> circumvent the protections this gives.
>> 
>> It should be noted that this has been a valid concern for every new O_*
>> flag introduced (and yet we still introduced new flags, despite the
>> concern) -- though to be fair, O_TMPFILE actually does have a
>> work-around with the O_DIRECTORY mask setup.
>> 
>> The openat2() set adds O_EMPTYPATH -- though in fairness it's also
>> backwards compatible because empty path strings have always given ENOENT
>> (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
>> 
>>> Maybe this should be a new flag that is only usable in the new openat2()
>>> syscall that's still under discussion? That syscall will enforce that
>>> all flags are recognized. You presumably wouldn't need the sysctl if you
>>> went that route too.
>> 
>> I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
>> how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
>> it, since I'd heard about this work through the grape-vine).
>> 
> 
> I rather like the idea of having openat2 fds be non-executable by
> default, and having userland request it specifically via O_MAYEXEC (or
> some similar openat2 flag) if it's needed. Then you could add an
> UPGRADE_EXEC flag instead?
> 
> That seems like something reasonable to do with a brand new API, and
> might be very helpful for preventing certain classes of attacks.
> 
> 

There are at least four concepts of executability here:

- Just check the file mode and any other relevant permissions. Return a normal fd.  Makes sense for script interpreters, perhaps.

- Make the fd fexecve-able.

- Make the resulting fd mappable PROT_EXEC.

- Make the resulting fd upgradable.

I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 20:06             ` Andy Lutomirski
@ 2019-09-06 20:51               ` Jeff Layton
  2019-09-06 21:27                 ` Andy Lutomirski
  2019-09-06 22:12                 ` Aleksa Sarai
  2019-09-09  9:33               ` Mickaël Salaün
  1 sibling, 2 replies; 45+ messages in thread
From: Jeff Layton @ 2019-09-06 20:51 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Aleksa Sarai, Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
> > On Sep 6, 2019, at 12:43 PM, Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > > On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > > > while still being able to run on older kernels.
> > > > > > 
> > > > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > > > > > with EINVAL, try again without O_MAYEXEC?
> > > > > 
> > > > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > > > older kernel to use O_MAYEXEC.
> > > > > 
> > > > 
> > > > Well...maybe. What about existing programs that are sending down bogus
> > > > open flags? Once you turn this on, they may break...or provide a way to
> > > > circumvent the protections this gives.
> > > 
> > > It should be noted that this has been a valid concern for every new O_*
> > > flag introduced (and yet we still introduced new flags, despite the
> > > concern) -- though to be fair, O_TMPFILE actually does have a
> > > work-around with the O_DIRECTORY mask setup.
> > > 
> > > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > > backwards compatible because empty path strings have always given ENOENT
> > > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > > 
> > > > Maybe this should be a new flag that is only usable in the new openat2()
> > > > syscall that's still under discussion? That syscall will enforce that
> > > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > > went that route too.
> > > 
> > > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > > it, since I'd heard about this work through the grape-vine).
> > > 
> > 
> > I rather like the idea of having openat2 fds be non-executable by
> > default, and having userland request it specifically via O_MAYEXEC (or
> > some similar openat2 flag) if it's needed. Then you could add an
> > UPGRADE_EXEC flag instead?
> > 
> > That seems like something reasonable to do with a brand new API, and
> > might be very helpful for preventing certain classes of attacks.
> > 
> > 
> 
> There are at least four concepts of executability here:
> 
> - Just check the file mode and any other relevant permissions. Return a normal fd.  Makes sense for script interpreters, perhaps.
> 
> - Make the fd fexecve-able.
> 
> - Make the resulting fd mappable PROT_EXEC.
> 
> - Make the resulting fd upgradable.
> 
> I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.

Good point. Upgradability is definitely orthogonal, though the idea
there is to alter the default behavior. If the default is NOEXEC then
UPGRADE_EXEC would make sense.

In any case, I was mostly thinking about the middle two in your list
above. After more careful reading of the patches, I now get get that
Mickaël is more interested in the first, and that's really a different
sort of use-case.

Most opens never result in the fd being fed to fexecve or mmapped with
PROT_EXEC, so having userland explicitly opt-in to allowing that during
the open sounds like a reasonable thing to do.

But I get that preventing execution via script interpreters of files
that are not executable might be something nice to have.

Perhaps we need two flags for openat2?

OA2_MAYEXEC : test that permissions allow execution and that the file
doesn't reside on a noexec mount before allowing the open

OA2_EXECABLE : only allow fexecve or mmapping with PROT_EXEC if the fd
was opened with this

-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 20:51               ` Jeff Layton
@ 2019-09-06 21:27                 ` Andy Lutomirski
  2019-09-06 22:12                 ` Aleksa Sarai
  1 sibling, 0 replies; 45+ messages in thread
From: Andy Lutomirski @ 2019-09-06 21:27 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Aleksa Sarai, Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, LKML, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	James Morris, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	Kernel Hardening, Linux API, LSM List, Linux FS Devel

> On Sep 6, 2019, at 1:51 PM, Jeff Layton <jlayton@kernel.org> wrote:
>
> On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
>
>> I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.
>
> Good point. Upgradability is definitely orthogonal, though the idea
> there is to alter the default behavior. If the default is NOEXEC then
> UPGRADE_EXEC would make sense.
>
> In any case, I was mostly thinking about the middle two in your list
> above. After more careful reading of the patches, I now get get that
> Mickaël is more interested in the first, and that's really a different
> sort of use-case.
>
> Most opens never result in the fd being fed to fexecve or mmapped with
> PROT_EXEC, so having userland explicitly opt-in to allowing that during
> the open sounds like a reasonable thing to do.
>
> But I get that preventing execution via script interpreters of files
> that are not executable might be something nice to have.
>
> Perhaps we need two flags for openat2?
>
> OA2_MAYEXEC : test that permissions allow execution and that the file
> doesn't reside on a noexec mount before allowing the open
>
> OA2_EXECABLE : only allow fexecve or mmapping with PROT_EXEC if the fd
> was opened with this
>
>
>

We could go one step farther and have three masks: check_perms,
fd_perms, and upgrade_perms.  check_perms says “fail if I don’t have
these perms”.  fd_perms is the permissions on the returned fd, and
upgrade_perms is the upgrade mask.  (fd_perms  & ~check_perms) != 0 is
an error.  This makes it possible to say "I want to make sure the file
is writable, but I don't actually want to write to it", which could
plausibly be useful.

I would argue that these things should have new, sane bits, e.g.
FILE_READ, FILE_WRITE, and FILE_EXECUTE (or maybe FILE_MAP_EXEC and
FILE_EXECVE).  And maybe there should be at least 16 bits for each
mask reserved.  Windows has a lot more mode bits than Linux, and it's
not entirely nuts.  We do *not* need any direct equivalent of O_RDWR
for openat2().

--Andy

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 19:43           ` Jeff Layton
  2019-09-06 20:06             ` Andy Lutomirski
@ 2019-09-06 22:05             ` Aleksa Sarai
  2019-09-06 22:18               ` Aleksa Sarai
  1 sibling, 1 reply; 45+ messages in thread
From: Aleksa Sarai @ 2019-09-06 22:05 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]

On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > > while still being able to run on older kernels.
> > > > > 
> > > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > > > > with EINVAL, try again without O_MAYEXEC?
> > > > 
> > > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > > older kernel to use O_MAYEXEC.
> > > > 
> > > 
> > > Well...maybe. What about existing programs that are sending down bogus
> > > open flags? Once you turn this on, they may break...or provide a way to
> > > circumvent the protections this gives.
> > 
> > It should be noted that this has been a valid concern for every new O_*
> > flag introduced (and yet we still introduced new flags, despite the
> > concern) -- though to be fair, O_TMPFILE actually does have a
> > work-around with the O_DIRECTORY mask setup.
> > 
> > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > backwards compatible because empty path strings have always given ENOENT
> > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > 
> > > Maybe this should be a new flag that is only usable in the new openat2()
> > > syscall that's still under discussion? That syscall will enforce that
> > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > went that route too.
> > 
> > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > it, since I'd heard about this work through the grape-vine).
> > 
> 
> I rather like the idea of having openat2 fds be non-executable by
> default, and having userland request it specifically via O_MAYEXEC (or
> some similar openat2 flag) if it's needed. Then you could add an
> UPGRADE_EXEC flag instead?
> 
> That seems like something reasonable to do with a brand new API, and
> might be very helpful for preventing certain classes of attacks.

In that case, maybe openat2(2) should default to not allowing any
upgrades by default? The reason I pitched UPGRADE_NOEXEC is because
UPGRADE_NO{READ,WRITE} are the existing @how->upgrade_mask flags.

However, I just noticed something else about this series -- if you do
O_PATH|O_MAYEXEC the new flag gets ignored. Given that you can do
fexecve(2) on an O_PATH (and O_PATHs have some other benefits), is this
something that we'd want to have?

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 20:51               ` Jeff Layton
  2019-09-06 21:27                 ` Andy Lutomirski
@ 2019-09-06 22:12                 ` Aleksa Sarai
  1 sibling, 0 replies; 45+ messages in thread
From: Aleksa Sarai @ 2019-09-06 22:12 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Andy Lutomirski, Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 5208 bytes --]

On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
> > > On Sep 6, 2019, at 12:43 PM, Jeff Layton <jlayton@kernel.org> wrote:
> > > 
> > > > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > > > On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > > > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > > > > while still being able to run on older kernels.
> > > > > > > 
> > > > > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > > > > > > with EINVAL, try again without O_MAYEXEC?
> > > > > > 
> > > > > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > > > > older kernel to use O_MAYEXEC.
> > > > > > 
> > > > > 
> > > > > Well...maybe. What about existing programs that are sending down bogus
> > > > > open flags? Once you turn this on, they may break...or provide a way to
> > > > > circumvent the protections this gives.
> > > > 
> > > > It should be noted that this has been a valid concern for every new O_*
> > > > flag introduced (and yet we still introduced new flags, despite the
> > > > concern) -- though to be fair, O_TMPFILE actually does have a
> > > > work-around with the O_DIRECTORY mask setup.
> > > > 
> > > > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > > > backwards compatible because empty path strings have always given ENOENT
> > > > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > > > 
> > > > > Maybe this should be a new flag that is only usable in the new openat2()
> > > > > syscall that's still under discussion? That syscall will enforce that
> > > > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > > > went that route too.
> > > > 
> > > > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > > > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > > > it, since I'd heard about this work through the grape-vine).
> > > > 
> > > 
> > > I rather like the idea of having openat2 fds be non-executable by
> > > default, and having userland request it specifically via O_MAYEXEC (or
> > > some similar openat2 flag) if it's needed. Then you could add an
> > > UPGRADE_EXEC flag instead?
> > > 
> > > That seems like something reasonable to do with a brand new API, and
> > > might be very helpful for preventing certain classes of attacks.
> > > 
> > > 
> > 
> > There are at least four concepts of executability here:
> > 
> > - Just check the file mode and any other relevant permissions. Return a normal fd.  Makes sense for script interpreters, perhaps.
> > 
> > - Make the fd fexecve-able.
> > 
> > - Make the resulting fd mappable PROT_EXEC.
> > 
> > - Make the resulting fd upgradable.
> > 
> > I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.
> 
> Good point. Upgradability is definitely orthogonal, though the idea
> there is to alter the default behavior. If the default is NOEXEC then
> UPGRADE_EXEC would make sense.
> 
> In any case, I was mostly thinking about the middle two in your list
> above. After more careful reading of the patches, I now get get that
> Mickaël is more interested in the first, and that's really a different
> sort of use-case.
> 
> Most opens never result in the fd being fed to fexecve or mmapped with
> PROT_EXEC, so having userland explicitly opt-in to allowing that during
> the open sounds like a reasonable thing to do.
> 
> But I get that preventing execution via script interpreters of files
> that are not executable might be something nice to have.

My first glance at the patch lead me to believe that this was about
blocking at fexecve()-time (which was what my first attempt at this
problem looked like) -- hence why I mentioned the upgrade_mask stuff
(because of the dances you can do with O_PATH, if blocking at
fexecve()-time was the goal then you seriously do need the upgrade_mask
and "O_PATH mask" in order for it to be even slightly secure).

But I also agree this is useful, and we can always add FMODE_EXEC,
FMODE_MAP_EXEC, and FMODE_UPGRADE_EXEC (and the related bits) at a later
date.

> Perhaps we need two flags for openat2?
> 
> OA2_MAYEXEC : test that permissions allow execution and that the file
> doesn't reside on a noexec mount before allowing the open
> 
> OA2_EXECABLE : only allow fexecve or mmapping with PROT_EXEC if the fd
> was opened with this

That seems reasonable to me. The only thing is that there currently
isn't any code to restrict fexecve() or PROT_EXEC in that fashion
(doubly so when you consider binfmt_script). So if we want to make
certain things default behaviour (such as disallowing exec by default)
we'd need to get the PROT_EXEC restriction work done first.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 22:05             ` Aleksa Sarai
@ 2019-09-06 22:18               ` Aleksa Sarai
  0 siblings, 0 replies; 45+ messages in thread
From: Aleksa Sarai @ 2019-09-06 22:18 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Mickaël Salaün, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
	Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]

On 2019-09-07, Aleksa Sarai <cyphar@cyphar.com> wrote:
> On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > > > while still being able to run on older kernels.
> > > > > > 
> > > > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> > > > > > with EINVAL, try again without O_MAYEXEC?
> > > > > 
> > > > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > > > older kernel to use O_MAYEXEC.
> > > > > 
> > > > 
> > > > Well...maybe. What about existing programs that are sending down bogus
> > > > open flags? Once you turn this on, they may break...or provide a way to
> > > > circumvent the protections this gives.
> > > 
> > > It should be noted that this has been a valid concern for every new O_*
> > > flag introduced (and yet we still introduced new flags, despite the
> > > concern) -- though to be fair, O_TMPFILE actually does have a
> > > work-around with the O_DIRECTORY mask setup.
> > > 
> > > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > > backwards compatible because empty path strings have always given ENOENT
> > > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > > 
> > > > Maybe this should be a new flag that is only usable in the new openat2()
> > > > syscall that's still under discussion? That syscall will enforce that
> > > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > > went that route too.
> > > 
> > > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > > it, since I'd heard about this work through the grape-vine).
> > > 
> > 
> > I rather like the idea of having openat2 fds be non-executable by
> > default, and having userland request it specifically via O_MAYEXEC (or
> > some similar openat2 flag) if it's needed. Then you could add an
> > UPGRADE_EXEC flag instead?
> > 
> > That seems like something reasonable to do with a brand new API, and
> > might be very helpful for preventing certain classes of attacks.
> 
> In that case, maybe openat2(2) should default to not allowing any
> upgrades by default? The reason I pitched UPGRADE_NOEXEC is because
> UPGRADE_NO{READ,WRITE} are the existing @how->upgrade_mask flags.

Sorry, another issue is that there isn't a current way to really
restrict fexecve() permissions (from my [limited] understanding,
__FMODE_EXEC isn't the right thing to use) -- so we can't blanket block
exec through openat2() O_PATH descriptors and add UPGRADE_EXEC later.

We would have to implement FMODE_EXEC (and FMODE_MAP_EXEC as you
suggested) in order to implement FMODE_UPGRADE_EXEC before we could even
get a first version of openat2(2) in. Though, I do (a little
begrudgingly) agree that we should have a safe default if possible
(magical O_PATH reopening trickery is something that most people don't
know about and probably wouldn't want to happen if they did).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
  2019-09-06 19:26       ` Andy Lutomirski
@ 2019-09-06 22:44         ` Aleksa Sarai
  2019-09-09  9:09           ` Mickaël Salaün
  0 siblings, 1 reply; 45+ messages in thread
From: Aleksa Sarai @ 2019-09-06 22:44 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Steve Grubb, Florian Weimer, Mickaël Salaün,
	linux-kernel, Alexei Starovoitov, Al Viro, Andy Lutomirski,
	Christian Heimes, Daniel Borkmann, Eric Chiang, James Morris,
	Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
	Matthew Wilcox, Michael Kerrisk, Mickaël Salaün,
	Mimi Zohar, Philippe Trébuchet, Scott Shell,
	Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
	Thibaut S autereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]

On 2019-09-06, Andy Lutomirski <luto@amacapital.net> wrote:
> > On Sep 6, 2019, at 12:07 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > 
> >> On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
> >> * Steve Grubb:
> >>> Now with LD_AUDIT
> >>> $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
> >>> 2>&1 | grep passwd openat(3, "passwd", O_RDONLY)           = 4
> >>> 
> >>> No O_CLOEXEC flag.
> >> 
> >> I think you need to explain in detail why you consider this a problem.
> > 
> > Because you can strip the O_MAYEXEC flag from being passed into the kernel. 
> > Once you do that, you defeat the security mechanism because it never gets 
> > invoked. The issue is that the only thing that knows _why_ something is being 
> > opened is user space. With this mechanism, you can attempt to pass this 
> > reason to the kernel so that it may see if policy permits this. But you can 
> > just remove the flag.
> 
> I’m with Florian here. Once you are executing code in a process, you
> could just emulate some other unapproved code. This series is not
> intended to provide the kind of absolute protection you’re imagining.

I also agree, though I think that there is a separate argument to be
made that there are two possible problems with O_MAYEXEC (which might
not be really big concerns):

  * It's very footgun-prone if you didn't call O_MAYEXEC yourself and
    you pass the descriptor elsewhere. You need to check f_flags to see
    if it contains O_MAYEXEC. Maybe there is an argument to be made that
    passing O_MAYEXECs around isn't a valid use-case, but in that case
    there should be some warnings about that.

  * There's effectively a TOCTOU flaw (even if you are sure O_MAYEXEC is
    in f_flags) -- if the filesystem becomes re-mounted noexec (or the
    file has a-x permissions) after you've done the check you won't get
    hit with an error when you go to use the file descriptor later.

To fix both you'd need to do what you mention later:

> What the kernel *could* do is prevent mmapping a non-FMODE_EXEC file
> with PROT_EXEC, which would indeed have a real effect (in an iOS-like
> world, for example) but would break many, many things.

And I think this would be useful (with the two possible ways of
executing .text split into FMODE_EXEC and FMODE_MAP_EXEC, as mentioned
in a sister subthread), but would have to be opt-in for the obvious
reason you outlined. However, we could make it the default for
openat2(2) -- assuming we can agree on what the semantics of a
theoretical FMODE_EXEC should be.

And of course we'd need to do FMODE_UPGRADE_EXEC (which would need to
also permit fexecve(2) though probably not PROT_EXEC -- I don't think
you can mmap() an O_PATH descriptor).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
  2019-09-06 15:24 [PATCH v2 0/5] Add support for O_MAYEXEC Mickaël Salaün
                   ` (5 preceding siblings ...)
  2019-09-06 18:50 ` [PATCH v2 0/5] Add support for O_MAYEXEC Steve Grubb
@ 2019-09-09  0:16 ` James Morris
  6 siblings, 0 replies; 45+ messages in thread
From: James Morris @ 2019-09-09  0:16 UTC (permalink / raw)
  To: Mickaël Salaün
  Cc: linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	Florian Weimer, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
	Mickaël Salaün, Mimi Zohar, Philippe Trébuchet,
	Scott Shell, Sean Christopherson, Shuah Khan, Song Liu,
	Steve Dower, Steve Grubb, Thibaut Sautereau, Vincent Strubel,
	Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel, Mimi Zohar

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Fri, 6 Sep 2019, Mickaël Salaün wrote:

> Furthermore, the security policy can also be delegated to an LSM, either
> a MAC system or an integrity system.  For instance, the new kernel
> MAY_OPENEXEC flag closes a major IMA measurement/appraisal interpreter
> integrity gap by bringing the ability to check the use of scripts [2].

To clarify, scripts are already covered by IMA if they're executed 
directly, and the gap is when invoking a script as a parameter to the 
interpreter (and for any sourced files). In that case only the interpreter 
is measured/appraised, unless there's a rule also covering the script 
file(s).

See:
https://en.opensuse.org/SDB:Ima_evm#script-behaviour

In theory you could probably also close the gap by modifying the 
interpreters to check for the execute bit on any file opened for 
interpretation (as earlier suggested by Steve Grubb), and then you could 
have IMA measure/appraise all files with +x.  I suspect this could get 
messy in terms of unwanted files being included, and the MAY_OPENEXEC flag 
has cleaner semantics.



-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
  2019-09-06 22:44         ` Aleksa Sarai
@ 2019-09-09  9:09           ` Mickaël Salaün
  0 siblings, 0 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-09  9:09 UTC (permalink / raw)
  To: Aleksa Sarai, Andy Lutomirski
  Cc: Steve Grubb, Florian Weimer, Mickaël Salaün,
	linux-kernel, Alexei Starovoitov, Al Viro, Andy Lutomirski,
	Christian Heimes, Daniel Borkmann, Eric Chiang, James Morris,
	Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
	Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Thibaut S autereau,
	Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
	linux-security-module, linux-fsdevel


On 07/09/2019 00:44, Aleksa Sarai wrote:
> On 2019-09-06, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Sep 6, 2019, at 12:07 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>>>
>>>> On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
>>>> * Steve Grubb:
>>>>> Now with LD_AUDIT
>>>>> $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
>>>>> 2>&1 | grep passwd openat(3, "passwd", O_RDONLY)           = 4
>>>>>
>>>>> No O_CLOEXEC flag.
>>>>
>>>> I think you need to explain in detail why you consider this a problem.

Right, LD_PRELOAD and such things are definitely not part of the threat
model for O_MAYEXEC, on purpose, because this must be addressed with
other security mechanism (e.g. correct file system access-control, IMA
policy, SELinux or other LSM security policies). This is a requirement
for O_MAYEXEC to be useful.

An interpreter is just a flexible program which is generic and doesn't
have other purpose other than behaving accordingly to external rules
(i.e. scripts). If you don't trust your interpreter, it should not be
executable in the first place. O_MAYEXEC enables to restrict the use of
(some) interpreters accordingly to a *global* system security policy.

>>>
>>> Because you can strip the O_MAYEXEC flag from being passed into the kernel.
>>> Once you do that, you defeat the security mechanism because it never gets
>>> invoked. The issue is that the only thing that knows _why_ something is being
>>> opened is user space. With this mechanism, you can attempt to pass this
>>> reason to the kernel so that it may see if policy permits this. But you can
>>> just remove the flag.
>>
>> I’m with Florian here. Once you are executing code in a process, you
>> could just emulate some other unapproved code. This series is not
>> intended to provide the kind of absolute protection you’re imagining.
>
> I also agree, though I think that there is a separate argument to be
> made that there are two possible problems with O_MAYEXEC (which might
> not be really big concerns):
>
>   * It's very footgun-prone if you didn't call O_MAYEXEC yourself and
>     you pass the descriptor elsewhere. You need to check f_flags to see
>     if it contains O_MAYEXEC. Maybe there is an argument to be made that
>     passing O_MAYEXECs around isn't a valid use-case, but in that case
>     there should be some warnings about that.

That could be an issue if you don't trust your system, especially if the
mount points (and the "noexec" option) can be changed by untrusted
users. As I said above, there is a requirement for basic security
properties as a meaningful file system access control, and obviously not
letting any user change mount points (which can lead to much sever
security issues anyway).

If a process A pass a FD to an interpreter B, then the interpreter B
must trust the process A. Moreover, being able to tell if the FD was
open with O_MAYEXEC and relying on it may create a wrong feeling of
security. As I said in a previous email, being able to probe for
O_MAYEXEC does not make sense because it would not be enough to
know the system policy (either this flag is enforced or not, for mount
points, based on xattr, time…). The main goal of O_MAYEXEC is to ask the
kernel, on a trusted link (hence without LD_PRELOAD-like interfering),
for a file which is allowed to be interpreted/executed by this interpreter.

To be able to correctly handle the case you pointed out (FD passing),
either an existing or a new LSM should handle this behavior according to
the origin of the FD and the chain of processes getting it.

Some advanced LSM rules could tie interpreters with scripts dedicated to
them, and have different behavior for the same scripts but with
different interpreters.

>
>   * There's effectively a TOCTOU flaw (even if you are sure O_MAYEXEC is
>     in f_flags) -- if the filesystem becomes re-mounted noexec (or the
>     file has a-x permissions) after you've done the check you won't get
>     hit with an error when you go to use the file descriptor later.

Again, the threat model needs to be appropriate to make O_MAYEXEC
useful. The security policies of the system need to be seen as a whole,
and updated as such.

As for most file system access control on Linux, it may be possible to
have TOCTOU, but the whole system should be designed to protect against
that. For example, changing file access control (e.g. mount point
options) without a reboot may lead to inconsistent security properties,
which is why such thing are discouraged by some access control systems
(e.g. SELinux).

>
> To fix both you'd need to do what you mention later:
>
>> What the kernel *could* do is prevent mmapping a non-FMODE_EXEC file
>> with PROT_EXEC, which would indeed have a real effect (in an iOS-like
>> world, for example) but would break many, many things.
>
> And I think this would be useful (with the two possible ways of
> executing .text split into FMODE_EXEC and FMODE_MAP_EXEC, as mentioned
> in a sister subthread), but would have to be opt-in for the obvious
> reason you outlined. However, we could make it the default for
> openat2(2) -- assuming we can agree on what the semantics of a
> theoretical FMODE_EXEC should be.
>
> And of course we'd need to do FMODE_UPGRADE_EXEC (which would need to
> also permit fexecve(2) though probably not PROT_EXEC -- I don't think
> you can mmap() an O_PATH descriptor).

The mmapping restriction may be interesting but it is a different use
case. This series address the interpreter/script problem. Either the
script may be mapped executable is the choice of the interpreter. In
most cases, no script are mapped as such, exactly because they are
interpreted by a process but not by the CPU.


--
Mickaël Salaün

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 18:41             ` Andy Lutomirski
@ 2019-09-09  9:18               ` Mickaël Salaün
  2019-09-09 15:49                 ` Andy Lutomirski
  0 siblings, 1 reply; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-09  9:18 UTC (permalink / raw)
  To: Andy Lutomirski, Jeff Layton
  Cc: Florian Weimer, Mickaël Salaün, linux-kernel,
	Aleksa Sarai, Alexei Starovoitov, Al Viro, Andy Lutomirski,
	Christian Heimes, Daniel Borkmann, Eric Chiang, James Morris,
	Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
	Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel


On 06/09/2019 20:41, Andy Lutomirski wrote:
>
>
>> On Sep 6, 2019, at 11:38 AM, Jeff Layton <jlayton@kernel.org> wrote:
>>
>>> On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
>>>> On 06/09/2019 18:48, Jeff Layton wrote:
>>>>> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>>>>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>>>>> while still being able to run on older kernels.
>>>>>>
>>>>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>>>>>> with EINVAL, try again without O_MAYEXEC?
>>>>>
>>>>> The kernel ignore unknown open(2) flags, so yes, it is safe even for
>>>>> older kernel to use O_MAYEXEC.
>>>>>
>>>>
>>>> Well...maybe. What about existing programs that are sending down bogus
>>>> open flags? Once you turn this on, they may break...or provide a way to
>>>> circumvent the protections this gives.
>>>
>>> Well, I don't think we should nor could care about bogus programs that
>>> do not conform to the Linux ABI.
>>>
>>
>> But they do conform. The ABI is just undefined here. Unknown flags are
>> ignored so we never really know if $random_program may be setting them.
>>
>>>> Maybe this should be a new flag that is only usable in the new openat2()
>>>> syscall that's still under discussion? That syscall will enforce that
>>>> all flags are recognized. You presumably wouldn't need the sysctl if you
>>>> went that route too.
>>>
>>> Here is a thread about a new syscall:
>>> https://lore.kernel.org/lkml/1544699060.6703.11.camel@linux.ibm.com/
>>>
>>> I don't think it fit well with auditing nor integrity. Moreover using
>>> the current open(2) behavior of ignoring unknown flags fit well with the
>>> usage of O_MAYEXEC (because it is only a hint to the kernel about the
>>> use of the *opened* file).
>>>
>>
>> The fact that open and openat didn't vet unknown flags is really a bug.
>>
>> Too late to fix it now, of course, and as Aleksa points out, we've
>> worked around that in the past. Now though, we have a new openat2
>> syscall on the horizon. There's little need to continue these sorts of
>> hacks.
>>
>> New open flags really have no place in the old syscalls, IMO.
>>
>>>> Anyone that wants to use this will have to recompile anyway. If the
>>>> kernel doesn't support openat2 or if the flag is rejected then you know
>>>> that you have no O_MAYEXEC support and can decide what to do.
>>>
>>> If we want to enforce a security policy, we need to either be the system
>>> administrator or the distro developer. If a distro ship interpreters
>>> using this flag, we don't need to recompile anything, but we need to be
>>> able to control the enforcement according to the mount point
>>> configuration (or an advanced MAC, or an IMA config). I don't see why an
>>> userspace process should check if this flag is supported or not, it
>>> should simply use it, and the sysadmin will enable an enforcement if it
>>> makes sense for the whole system.
>>>
>>
>> A userland program may need to do other risk mitigation if it sets
>> O_MAYEXEC and the kernel doesn't recognize it.
>>
>> Personally, here's what I'd suggest:
>>
>> - Base this on top of the openat2 set
>> - Change it that so that openat2() files are non-executable by default. Anyone wanting to do that needs to set O_MAYEXEC or upgrade the fd somehow.
>> - Only have the openat2 syscall pay attention to O_MAYEXEC. Let open and openat continue ignoring the new flag.
>>
>> That works around a whole pile of potential ABI headaches. Note that
>> we'd need to make that decision before the openat2 patches are merged.
>>
>> Even better would be to declare the new flag in some openat2-only flag
>> space, so there's no confusion about it being supported by legacy open
>> calls.
>>
>> If glibc wants to implement an open -> openat2 wrapper in userland
>> later, it can set that flag in the wrapper implicitly to emulate the old
>> behavior.
>>
>> Given that you're going to have to recompile software to take advantage
>> of this anyway, what's the benefit to changing legacy syscalls?
>>
>>>>>> Or do I risk disabling this security feature if I do that?
>>>>>
>>>>> It is only a security feature if the kernel support it, otherwise it is
>>>>> a no-op.
>>>>>
>>>>
>>>> With a security feature, I think we really want userland to aware of
>>>> whether it works.
>>>
>>> If userland would like to enforce something, it can already do it
>>> without any kernel modification. The goal of the O_MAYEXEC flag is to
>>> enable the kernel, hence sysadmins or system designers, to enforce a
>>> global security policy that makes sense.
>>>
>>
>> I don't see how this helps anything if you can't tell whether the kernel
>> recognizes the damned thing. Also, our track record with global sysctl
>> switches like this is pretty poor. They're an administrative headache as
>> well as a potential attack vector.
>
> I tend to agree. The sysctl seems like it’s asking for trouble. I can see an ld.so.conf option to turn this thing off making sense.

The sysctl is required to enable the adoption of this flag without
breaking existing systems. Current systems may have "noexec" on mount
points containing scripts. Without giving the ability to the sysadmin to
control that behavior, updating to a newer version of an interpreter
using O_MAYEXEC may break such systems.

How would you do this with ld.so.conf ?


--
Mickaël Salaün

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 19:03             ` James Morris
@ 2019-09-09  9:25               ` Mickaël Salaün
  2019-09-09 10:12                 ` James Morris
  2019-09-09 11:54                 ` Aleksa Sarai
  0 siblings, 2 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-09  9:25 UTC (permalink / raw)
  To: James Morris, Jeff Layton
  Cc: Florian Weimer, Mickaël Salaün, linux-kernel,
	Aleksa Sarai, Alexei Starovoitov, Al Viro, Andy Lutomirski,
	Christian Heimes, Daniel Borkmann, Eric Chiang, Jan Kara,
	Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
	Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel


On 06/09/2019 21:03, James Morris wrote:
> On Fri, 6 Sep 2019, Jeff Layton wrote:
>
>> The fact that open and openat didn't vet unknown flags is really a bug.
>>
>> Too late to fix it now, of course, and as Aleksa points out, we've
>> worked around that in the past. Now though, we have a new openat2
>> syscall on the horizon. There's little need to continue these sorts of
>> hacks.
>>
>> New open flags really have no place in the old syscalls, IMO.
>
> Agree here. It's unfortunate but a reality and Linus will reject any such
> changes which break existing userspace.

Do you mean that adding new flags to open(2) is not possible?

Does it means that unspecified behaviors are definitely part of the
Linux specification and can't be fixed?

As I said, O_MAYEXEC should be ignored if it is not supported by the
kernel, which perfectly fit with the current open(2) flags behavior, and
should also behave the same with openat2(2).


--
Mickaël Salaün

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-06 20:06             ` Andy Lutomirski
  2019-09-06 20:51               ` Jeff Layton
@ 2019-09-09  9:33               ` Mickaël Salaün
  1 sibling, 0 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-09  9:33 UTC (permalink / raw)
  To: Andy Lutomirski, Jeff Layton
  Cc: Aleksa Sarai, Florian Weimer, Mickaël Salaün,
	linux-kernel, Alexei Starovoitov, Al Viro, Andy Lutomirski,
	Christian Heimes, Daniel Borkmann, Eric Chiang, James Morris,
	Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
	Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel


On 06/09/2019 22:06, Andy Lutomirski wrote:
>
>
>> On Sep 6, 2019, at 12:43 PM, Jeff Layton <jlayton@kernel.org> wrote:
>>
>>> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
>>>> On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
>>>>> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>>>>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>>>>> while still being able to run on older kernels.
>>>>>>
>>>>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>>>>>> with EINVAL, try again without O_MAYEXEC?
>>>>>
>>>>> The kernel ignore unknown open(2) flags, so yes, it is safe even for
>>>>> older kernel to use O_MAYEXEC.
>>>>>
>>>>
>>>> Well...maybe. What about existing programs that are sending down bogus
>>>> open flags? Once you turn this on, they may break...or provide a way to
>>>> circumvent the protections this gives.
>>>
>>> It should be noted that this has been a valid concern for every new O_*
>>> flag introduced (and yet we still introduced new flags, despite the
>>> concern) -- though to be fair, O_TMPFILE actually does have a
>>> work-around with the O_DIRECTORY mask setup.
>>>
>>> The openat2() set adds O_EMPTYPATH -- though in fairness it's also
>>> backwards compatible because empty path strings have always given ENOENT
>>> (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
>>>
>>>> Maybe this should be a new flag that is only usable in the new openat2()
>>>> syscall that's still under discussion? That syscall will enforce that
>>>> all flags are recognized. You presumably wouldn't need the sysctl if you
>>>> went that route too.
>>>
>>> I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
>>> how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
>>> it, since I'd heard about this work through the grape-vine).
>>>
>>
>> I rather like the idea of having openat2 fds be non-executable by
>> default, and having userland request it specifically via O_MAYEXEC (or
>> some similar openat2 flag) if it's needed. Then you could add an
>> UPGRADE_EXEC flag instead?
>>
>> That seems like something reasonable to do with a brand new API, and
>> might be very helpful for preventing certain classes of attacks.
>>
>>
>
> There are at least four concepts of executability here:
>
> - Just check the file mode and any other relevant permissions. Return a normal fd.  Makes sense for script interpreters, perhaps.

This is the purpose of this patch series. It doesn't make sense to add
memory restrictions nor constrain fexecve and such.


>
> - Make the fd fexecve-able.
>
> - Make the resulting fd mappable PROT_EXEC.
>
> - Make the resulting fd upgradable.
>
> I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.
>

--
Mickaël Salaün

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-09  9:25               ` Mickaël Salaün
@ 2019-09-09 10:12                 ` James Morris
  2019-09-09 10:54                   ` Mickaël Salaün
  2019-09-09 11:54                 ` Aleksa Sarai
  1 sibling, 1 reply; 45+ messages in thread
From: James Morris @ 2019-09-09 10:12 UTC (permalink / raw)
  To: Mickaël Salaün
  Cc: Jeff Layton, Florian Weimer, Mickaël Salaün,
	linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
	Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

On Mon, 9 Sep 2019, Mickaël Salaün wrote:

> 
> On 06/09/2019 21:03, James Morris wrote:
> > On Fri, 6 Sep 2019, Jeff Layton wrote:
> >
> >> The fact that open and openat didn't vet unknown flags is really a bug.
> >>
> >> Too late to fix it now, of course, and as Aleksa points out, we've
> >> worked around that in the past. Now though, we have a new openat2
> >> syscall on the horizon. There's little need to continue these sorts of
> >> hacks.
> >>
> >> New open flags really have no place in the old syscalls, IMO.
> >
> > Agree here. It's unfortunate but a reality and Linus will reject any such
> > changes which break existing userspace.
> 
> Do you mean that adding new flags to open(2) is not possible?
> 
> Does it means that unspecified behaviors are definitely part of the
> Linux specification and can't be fixed?

This is my understanding.

> 
> As I said, O_MAYEXEC should be ignored if it is not supported by the
> kernel, which perfectly fit with the current open(2) flags behavior, and
> should also behave the same with openat2(2).

The problem here is programs which are already using the value of 
O_MAYEXEC, which will break.  Hence, openat2(2).


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-09 10:12                 ` James Morris
@ 2019-09-09 10:54                   ` Mickaël Salaün
  2019-09-09 12:28                     ` Aleksa Sarai
  0 siblings, 1 reply; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-09 10:54 UTC (permalink / raw)
  To: James Morris
  Cc: Jeff Layton, Florian Weimer, Mickaël Salaün,
	linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
	Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel


On 09/09/2019 12:12, James Morris wrote:
> On Mon, 9 Sep 2019, Mickaël Salaün wrote:
>
>>
>> On 06/09/2019 21:03, James Morris wrote:
>>> On Fri, 6 Sep 2019, Jeff Layton wrote:
>>>
>>>> The fact that open and openat didn't vet unknown flags is really a bug.
>>>>
>>>> Too late to fix it now, of course, and as Aleksa points out, we've
>>>> worked around that in the past. Now though, we have a new openat2
>>>> syscall on the horizon. There's little need to continue these sorts of
>>>> hacks.
>>>>
>>>> New open flags really have no place in the old syscalls, IMO.
>>>
>>> Agree here. It's unfortunate but a reality and Linus will reject any such
>>> changes which break existing userspace.
>>
>> Do you mean that adding new flags to open(2) is not possible?
>>
>> Does it means that unspecified behaviors are definitely part of the
>> Linux specification and can't be fixed?
>
> This is my understanding.
>
>>
>> As I said, O_MAYEXEC should be ignored if it is not supported by the
>> kernel, which perfectly fit with the current open(2) flags behavior, and
>> should also behave the same with openat2(2).
>
> The problem here is programs which are already using the value of
> O_MAYEXEC, which will break.  Hence, openat2(2).

Well, it still depends on the sysctl, which doesn't enforce anything by
default, hence doesn't break existing behavior, and this unused flags
could be fixed/removed or reported by sysadmins or distro developers.


--
Mickaël Salaün

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-09  9:25               ` Mickaël Salaün
  2019-09-09 10:12                 ` James Morris
@ 2019-09-09 11:54                 ` Aleksa Sarai
  2019-09-09 12:28                   ` Mickaël Salaün
  1 sibling, 1 reply; 45+ messages in thread
From: Aleksa Sarai @ 2019-09-09 11:54 UTC (permalink / raw)
  To: Mickaël Salaün
  Cc: James Morris, Jeff Layton, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

On 2019-09-09, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> On 06/09/2019 21:03, James Morris wrote:
> > On Fri, 6 Sep 2019, Jeff Layton wrote:
> >
> >> The fact that open and openat didn't vet unknown flags is really a bug.
> >>
> >> Too late to fix it now, of course, and as Aleksa points out, we've
> >> worked around that in the past. Now though, we have a new openat2
> >> syscall on the horizon. There's little need to continue these sorts of
> >> hacks.
> >>
> >> New open flags really have no place in the old syscalls, IMO.
> >
> > Agree here. It's unfortunate but a reality and Linus will reject any such
> > changes which break existing userspace.
> 
> Do you mean that adding new flags to open(2) is not possible?

It is possible, as long as there is no case where a program that works
today (and passes garbage to the unused bits in flags) works with the
change.

O_TMPFILE was okay because it's actually two flags (one is O_DIRECTORY)
and no working program does file IO to a directory (there are also some
other tricky things done there, I'll admit I don't fully understand it).

O_EMPTYPATH works because it's a no-op with non-empty path strings, and
empty path strings have always given an error (so no working program
does it today).

However, O_MAYEXEC will result in programs that pass garbage bits to
potentially get -EACCES that worked previously.

> As I said, O_MAYEXEC should be ignored if it is not supported by the
> kernel, which perfectly fit with the current open(2) flags behavior, and
> should also behave the same with openat2(2).

NACK on having that behaviour with openat2(2). -EINVAL on unknown flags
is how all other syscalls work (any new syscall proposed today that
didn't do that would be rightly rejected), and is a quirk of open(2)
which unfortunately cannot be fixed. The fact that *every new O_ flag
needs to work around this problem* should be an indication that this
interface mis-design should not be allowed to infect any more syscalls.

Note that this point is regardless of the fact that O_MAYEXEC is a
*security* flag -- if userspace wants to have a secure fallback on
old kernels (which is "the right thing" to do) they would have to do
more work than necessary. And programs that don't care don't have to do
anything special.

However with -EINVAL, the programs doing "the right thing" get an easy
-EINVAL check. And programs that don't care can just un-set O_MAYEXEC
and retry. You should be forced to deal with the case where a flag is
not supported -- and this is doubly true of security flags!

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-09 10:54                   ` Mickaël Salaün
@ 2019-09-09 12:28                     ` Aleksa Sarai
  2019-09-09 12:33                       ` Mickaël Salaün
  0 siblings, 1 reply; 45+ messages in thread
From: Aleksa Sarai @ 2019-09-09 12:28 UTC (permalink / raw)
  To: Mickaël Salaün
  Cc: James Morris, Jeff Layton, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On 2019-09-09, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> On 09/09/2019 12:12, James Morris wrote:
> > On Mon, 9 Sep 2019, Mickaël Salaün wrote:
> >> As I said, O_MAYEXEC should be ignored if it is not supported by the
> >> kernel, which perfectly fit with the current open(2) flags behavior, and
> >> should also behave the same with openat2(2).
> >
> > The problem here is programs which are already using the value of
> > O_MAYEXEC, which will break.  Hence, openat2(2).
> 
> Well, it still depends on the sysctl, which doesn't enforce anything by
> default, hence doesn't break existing behavior, and this unused flags
> could be fixed/removed or reported by sysadmins or distro developers.

Okay, but then this means that new programs which really want to enforce
O_MAYEXEC (and know that they really do want this feature) won't be able
to unless an admin has set the relevant sysctl. Not to mention that the
old-kernel fallback will not cover the "it's disabled by the sysctl"
case -- so the fallback handling would need to be:

    int fd = open("foo", O_MAYEXEC|O_RDONLY);
    if (!(fcntl(fd, F_GETFL) & O_MAYEXEC))
        fallback();
    if (!sysctl_feature_is_enabled)
        fallback();

However, there is still a race here -- if an administrator enables
O_MAYEXEC after the program gets the fd, then you still won't hit the
fallback (and you can't tell that O_MAYEXEC checks weren't done).

You could fix the issue with the sysctl by clearing O_MAYEXEC from
f_flags if the sysctl is disabled. You could also avoid some of the
problems with it being a global setting by making it a prctl(2) which
processes can opt-in to (though this has its own major problems).

Sorry, but I'm just really not a fan of this.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-09 11:54                 ` Aleksa Sarai
@ 2019-09-09 12:28                   ` Mickaël Salaün
  0 siblings, 0 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-09 12:28 UTC (permalink / raw)
  To: Aleksa Sarai
  Cc: James Morris, Jeff Layton, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel


On 09/09/2019 13:54, Aleksa Sarai wrote:
> On 2019-09-09, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
>> On 06/09/2019 21:03, James Morris wrote:
>>> On Fri, 6 Sep 2019, Jeff Layton wrote:
>>>
>>>> The fact that open and openat didn't vet unknown flags is really a bug.
>>>>
>>>> Too late to fix it now, of course, and as Aleksa points out, we've
>>>> worked around that in the past. Now though, we have a new openat2
>>>> syscall on the horizon. There's little need to continue these sorts of
>>>> hacks.
>>>>
>>>> New open flags really have no place in the old syscalls, IMO.
>>>
>>> Agree here. It's unfortunate but a reality and Linus will reject any such
>>> changes which break existing userspace.
>>
>> Do you mean that adding new flags to open(2) is not possible?
>
> It is possible, as long as there is no case where a program that works
> today (and passes garbage to the unused bits in flags) works with the
> change.
>
> O_TMPFILE was okay because it's actually two flags (one is O_DIRECTORY)
> and no working program does file IO to a directory (there are also some
> other tricky things done there, I'll admit I don't fully understand it).
>
> O_EMPTYPATH works because it's a no-op with non-empty path strings, and
> empty path strings have always given an error (so no working program
> does it today).
>
> However, O_MAYEXEC will result in programs that pass garbage bits to
> potentially get -EACCES that worked previously.
>
>> As I said, O_MAYEXEC should be ignored if it is not supported by the
>> kernel, which perfectly fit with the current open(2) flags behavior, and
>> should also behave the same with openat2(2).
>
> NACK on having that behaviour with openat2(2). -EINVAL on unknown flags
> is how all other syscalls work (any new syscall proposed today that
> didn't do that would be rightly rejected), and is a quirk of open(2)
> which unfortunately cannot be fixed. The fact that *every new O_ flag
> needs to work around this problem* should be an indication that this
> interface mis-design should not be allowed to infect any more syscalls.

It's definitely OK (and a sane interface) to always return -EINVAL for
unknown flags with openat2(2) (and other new syscalls). With openat2(2),
userland need to handle the case where some flags may be unknown to the
kernel (and handling the fact that this syscall may be unknown too). So
there is not an issue with openat2(2).

However, *userland* should not try to infer possible security
restrictions from the O_MAYEXEC flag (then, my use of "ignore" above),
which may return -EACCES or not, according to the current running system
security policy.

Following this reasoning, the current behavior or open(2) is fine for
O_MAYEXEC. The openat2(2) strict flag handling (i.e. -EINVAL) is fine
too for O_MAYEXEC.

>
> Note that this point is regardless of the fact that O_MAYEXEC is a
> *security* flag -- if userspace wants to have a secure fallback on
> old kernels (which is "the right thing" to do) they would have to do
> more work than necessary. And programs that don't care don't have to do
> anything special.

Most of the time this reasoning is good for most security stuff.
However, the O_MAYEXEC flag is not a security feature on its own, it is
an indication to the kernel to how this file would be used by userland.
The *kernel* security policy may tell back to userland if the system
security policy allow it or not. Most of the time, Policy Decision
Points (PDP) and Policy Enforcement Points (PEP) are in the same
software component (e.g. the kernel). Here the kernel is the PDP and
userland interpreters are PDP. Obviously, it means that these
interpreters must be (sub)part of your TCB (thanks to other security
features).

>
> However with -EINVAL, the programs doing "the right thing" get an easy
> -EINVAL check. And programs that don't care can just un-set O_MAYEXEC
> and retry. You should be forced to deal with the case where a flag is
> not supported -- and this is doubly true of security flags!

I'm in favor of doing this for openat2(2) with O_MAYEXEC, but it is not
because of the "security purposes" of this flag, as I said above, it is
because it is a saner ABI that every syscall should follow. But again,
it doesn't change my point about open(2). :)


--
Mickaël Salaün

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-09 12:28                     ` Aleksa Sarai
@ 2019-09-09 12:33                       ` Mickaël Salaün
  0 siblings, 0 replies; 45+ messages in thread
From: Mickaël Salaün @ 2019-09-09 12:33 UTC (permalink / raw)
  To: Aleksa Sarai
  Cc: James Morris, Jeff Layton, Florian Weimer,
	Mickaël Salaün, linux-kernel, Alexei Starovoitov,
	Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
	Eric Chiang, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel


On 09/09/2019 14:28, Aleksa Sarai wrote:
> On 2019-09-09, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
>> On 09/09/2019 12:12, James Morris wrote:
>>> On Mon, 9 Sep 2019, Mickaël Salaün wrote:
>>>> As I said, O_MAYEXEC should be ignored if it is not supported by the
>>>> kernel, which perfectly fit with the current open(2) flags behavior, and
>>>> should also behave the same with openat2(2).
>>>
>>> The problem here is programs which are already using the value of
>>> O_MAYEXEC, which will break.  Hence, openat2(2).
>>
>> Well, it still depends on the sysctl, which doesn't enforce anything by
>> default, hence doesn't break existing behavior, and this unused flags
>> could be fixed/removed or reported by sysadmins or distro developers.
>
> Okay, but then this means that new programs which really want to enforce
> O_MAYEXEC (and know that they really do want this feature) won't be able
> to unless an admin has set the relevant sysctl. Not to mention that the
> old-kernel fallback will not cover the "it's disabled by the sysctl"
> case -- so the fallback handling would need to be:
>
>     int fd = open("foo", O_MAYEXEC|O_RDONLY);
>     if (!(fcntl(fd, F_GETFL) & O_MAYEXEC))
>         fallback();
>     if (!sysctl_feature_is_enabled)
>         fallback();
>
> However, there is still a race here -- if an administrator enables
> O_MAYEXEC after the program gets the fd, then you still won't hit the
> fallback (and you can't tell that O_MAYEXEC checks weren't done).

I just replied to this concern here:
https://lore.kernel.org/lkml/70e4244e-4dfb-6e67-416b-445e383aa1b5@ssi.gouv.fr/

>
> You could fix the issue with the sysctl by clearing O_MAYEXEC from
> f_flags if the sysctl is disabled. You could also avoid some of the
> problems with it being a global setting by making it a prctl(2) which
> processes can opt-in to (though this has its own major problems).

Security definition and enforcement should be manageable by sysadmins
and distro developers.

>
> Sorry, but I'm just really not a fan of this.

I guess there is some misunderstanding. I just replied to another thread
and I think it should answer your concerns (especially about the PDP and
PEP):
https://lore.kernel.org/lkml/70e4244e-4dfb-6e67-416b-445e383aa1b5@ssi.gouv.fr/


--
Mickaël Salaün

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
  2019-09-09  9:18               ` Mickaël Salaün
@ 2019-09-09 15:49                 ` Andy Lutomirski
  0 siblings, 0 replies; 45+ messages in thread
From: Andy Lutomirski @ 2019-09-09 15:49 UTC (permalink / raw)
  To: Mickaël Salaün
  Cc: Jeff Layton, Florian Weimer, Mickaël Salaün,
	linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
	Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
	James Morris, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
	Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
	Philippe Trébuchet, Scott Shell, Sean Christopherson,
	Shuah Khan, Song Liu, Steve Dower, Steve Grubb,
	Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
	kernel-hardening, linux-api, linux-security-module,
	linux-fsdevel


> On Sep 9, 2019, at 2:18 AM, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> 
> 
>> On 06/09/2019 20:41, Andy Lutomirski wrote:
>> 
>> 
>>>> On Sep 6, 2019, at 11:38 AM, Jeff Layton <jlayton@kernel.org> wrote:
>>>> 
>>>>> On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
>>>>>> On 06/09/2019 18:48, Jeff Layton wrote:
>>>>>>> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>>>>>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>>>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>>>>>> while still being able to run on older kernels.
>>>>>>> 
>>>>>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>>>>>>> with EINVAL, try again without O_MAYEXEC?
>>>>>> 
>>>>>> The kernel ignore unknown open(2) flags, so yes, it is safe even for
>>>>>> older kernel to use O_MAYEXEC.
>>>>>> 
>>>>> 
>>>>> Well...maybe. What about existing programs that are sending down bogus
>>>>> open flags? Once you turn this on, they may break...or provide a way to
>>>>> circumvent the protections this gives.
>>>> 
>>>> Well, I don't think we should nor could care about bogus programs that
>>>> do not conform to the Linux ABI.
>>>> 
>>> 
>>> But they do conform. The ABI is just undefined here. Unknown flags are
>>> ignored so we never really know if $random_program may be setting them.
>>> 
>>>>> Maybe this should be a new flag that is only usable in the new openat2()
>>>>> syscall that's still under discussion? That syscall will enforce that
>>>>> all flags are recognized. You presumably wouldn't need the sysctl if you
>>>>> went that route too.
>>>> 
>>>> Here is a thread about a new syscall:
>>>> https://lore.kernel.org/lkml/1544699060.6703.11.camel@linux.ibm.com/
>>>> 
>>>> I don't think it fit well with auditing nor integrity. Moreover using
>>>> the current open(2) behavior of ignoring unknown flags fit well with the
>>>> usage of O_MAYEXEC (because it is only a hint to the kernel about the
>>>> use of the *opened* file).
>>>> 
>>> 
>>> The fact that open and openat didn't vet unknown flags is really a bug.
>>> 
>>> Too late to fix it now, of course, and as Aleksa points out, we've
>>> worked around that in the past. Now though, we have a new openat2
>>> syscall on the horizon. There's little need to continue these sorts of
>>> hacks.
>>> 
>>> New open flags really have no place in the old syscalls, IMO.
>>> 
>>>>> Anyone that wants to use this will have to recompile anyway. If the
>>>>> kernel doesn't support openat2 or if the flag is rejected then you know
>>>>> that you have no O_MAYEXEC support and can decide what to do.
>>>> 
>>>> If we want to enforce a security policy, we need to either be the system
>>>> administrator or the distro developer. If a distro ship interpreters
>>>> using this flag, we don't need to recompile anything, but we need to be
>>>> able to control the enforcement according to the mount point
>>>> configuration (or an advanced MAC, or an IMA config). I don't see why an
>>>> userspace process should check if this flag is supported or not, it
>>>> should simply use it, and the sysadmin will enable an enforcement if it
>>>> makes sense for the whole system.
>>>> 
>>> 
>>> A userland program may need to do other risk mitigation if it sets
>>> O_MAYEXEC and the kernel doesn't recognize it.
>>> 
>>> Personally, here's what I'd suggest:
>>> 
>>> - Base this on top of the openat2 set
>>> - Change it that so that openat2() files are non-executable by default. Anyone wanting to do that needs to set O_MAYEXEC or upgrade the fd somehow.
>>> - Only have the openat2 syscall pay attention to O_MAYEXEC. Let open and openat continue ignoring the new flag.
>>> 
>>> That works around a whole pile of potential ABI headaches. Note that
>>> we'd need to make that decision before the openat2 patches are merged.
>>> 
>>> Even better would be to declare the new flag in some openat2-only flag
>>> space, so there's no confusion about it being supported by legacy open
>>> calls.
>>> 
>>> If glibc wants to implement an open -> openat2 wrapper in userland
>>> later, it can set that flag in the wrapper implicitly to emulate the old
>>> behavior.
>>> 
>>> Given that you're going to have to recompile software to take advantage
>>> of this anyway, what's the benefit to changing legacy syscalls?
>>> 
>>>>>>> Or do I risk disabling this security feature if I do that?
>>>>>> 
>>>>>> It is only a security feature if the kernel support it, otherwise it is
>>>>>> a no-op.
>>>>>> 
>>>>> 
>>>>> With a security feature, I think we really want userland to aware of
>>>>> whether it works.
>>>> 
>>>> If userland would like to enforce something, it can already do it
>>>> without any kernel modification. The goal of the O_MAYEXEC flag is to
>>>> enable the kernel, hence sysadmins or system designers, to enforce a
>>>> global security policy that makes sense.
>>>> 
>>> 
>>> I don't see how this helps anything if you can't tell whether the kernel
>>> recognizes the damned thing. Also, our track record with global sysctl
>>> switches like this is pretty poor. They're an administrative headache as
>>> well as a potential attack vector.
>> 
>> I tend to agree. The sysctl seems like it’s asking for trouble. I can see an ld.so.conf option to turn this thing off making sense.
> 
> The sysctl is required to enable the adoption of this flag without
> breaking existing systems. Current systems may have "noexec" on mount
> points containing scripts. Without giving the ability to the sysadmin to
> control that behavior, updating to a newer version of an interpreter
> using O_MAYEXEC may break such systems.
> 
> How would you do this with ld.so.conf ?
> 

By telling user code not to use O_MAYEXEC?

Alternatively, you could allow O_MAYEXEC even on a noexec mount and have a strong_noexec option that blocks it.

^ permalink raw reply	[flat|nested] 45+ messages in thread

end of thread, other threads:[~2019-09-09 15:49 UTC | newest]

Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-06 15:24 [PATCH v2 0/5] Add support for O_MAYEXEC Mickaël Salaün
2019-09-06 15:24 ` [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Mickaël Salaün
2019-09-06 15:56   ` Florian Weimer
2019-09-06 16:06     ` Mickaël Salaün
2019-09-06 16:48       ` Jeff Layton
2019-09-06 17:13         ` Aleksa Sarai
2019-09-06 19:43           ` Jeff Layton
2019-09-06 20:06             ` Andy Lutomirski
2019-09-06 20:51               ` Jeff Layton
2019-09-06 21:27                 ` Andy Lutomirski
2019-09-06 22:12                 ` Aleksa Sarai
2019-09-09  9:33               ` Mickaël Salaün
2019-09-06 22:05             ` Aleksa Sarai
2019-09-06 22:18               ` Aleksa Sarai
2019-09-06 17:14         ` Mickaël Salaün
2019-09-06 18:38           ` Jeff Layton
2019-09-06 18:41             ` Andy Lutomirski
2019-09-09  9:18               ` Mickaël Salaün
2019-09-09 15:49                 ` Andy Lutomirski
2019-09-06 18:44             ` Florian Weimer
2019-09-06 19:03             ` James Morris
2019-09-09  9:25               ` Mickaël Salaün
2019-09-09 10:12                 ` James Morris
2019-09-09 10:54                   ` Mickaël Salaün
2019-09-09 12:28                     ` Aleksa Sarai
2019-09-09 12:33                       ` Mickaël Salaün
2019-09-09 11:54                 ` Aleksa Sarai
2019-09-09 12:28                   ` Mickaël Salaün
2019-09-06 17:07       ` Aleksa Sarai
2019-09-06 17:20         ` Christian Brauner
2019-09-06 17:24           ` Mickaël Salaün
2019-09-06 17:40           ` Tycho Andersen
2019-09-06 18:27             ` Florian Weimer
2019-09-06 18:46               ` Tycho Andersen
2019-09-06 15:24 ` [PATCH v2 2/5] fs: Add a MAY_EXECMOUNT flag to infer the noexec mount propertie Mickaël Salaün
2019-09-06 15:24 ` [PATCH v2 3/5] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC Mickaël Salaün
2019-09-06 15:24 ` [PATCH v2 4/5] selftest/exec: Add tests for O_MAYEXEC enforcing Mickaël Salaün
2019-09-06 15:24 ` [PATCH v2 5/5] doc: Add documentation for the fs.open_mayexec_enforce sysctl Mickaël Salaün
2019-09-06 18:50 ` [PATCH v2 0/5] Add support for O_MAYEXEC Steve Grubb
2019-09-06 18:57   ` Florian Weimer
2019-09-06 19:07     ` Steve Grubb
2019-09-06 19:26       ` Andy Lutomirski
2019-09-06 22:44         ` Aleksa Sarai
2019-09-09  9:09           ` Mickaël Salaün
2019-09-09  0:16 ` James Morris

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).