Hi,
This sixth patch series mainly adds Kees Cook's file permission check
relocations which help to simplify and generalize the previous series.
I removed the MAY_EXECMOUNT flag patch which is not useful anymore with
this refactoring. I also removed the static enforcement configuration
through Kconfig to make this series simpler and because it works in pair
with mount configurations (i.e. requires the same capability:
CAP_SYS_ADMIN).
As requested by Mimi Zohar, I completed the series with one of her
patches for IMA. I also picked Kees Cook's patches to consolidate exec
permission checking into do_filp_open()'s flow:
https://lore.kernel.org/lkml/20200605160013.3954297-1-keescook@chromium.org/
# Goal of O_MAYEXEC
The goal of this patch series is to enable to control script execution
with interpreters help. A new O_MAYEXEC flag, usable through
openat2(2), is added to enable userspace script interpreters 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.
A simple system-wide security policy can be enforced by the system
administrator through a sysctl configuration consistent with the mount
points or the file access rights. The documentation patch explains the
prerequisites.
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 [1].
Other uses are expected, such as for magic-links [2], SGX integration
[3], bpffs [4] or IPE [5].
# Prerequisite of its use
Userspace needs 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 [7].
# Examples
The initial idea comes from CLIP OS 4 and the original implementation
has been used for more than 12 years:
https://github.com/clipos-archive/clipos4_doc
Chrome OS has a similar approach:
https://chromium.googlesource.com/chromiumos/docs/+/master/security/noexec_shell_scripts.md
Userland patches can be found here:
https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
Actually, there is more than the O_MAYEXEC changes (which matches this search)
e.g., to prevent Python interactive execution. There are patches for
Bash, Wine, Java (Icedtea), Busybox's ash, Perl and Python. There are
also some related patches which do not directly rely on O_MAYEXEC but
which restrict the use of browser plugins and extensions, which may be
seen as scripts too:
https://github.com/clipos-archive/clipos4_portage-overlay/tree/master/www-client
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
See also an overview article: https://lwn.net/Articles/820000/
This patch series can be applied on top of v5.8-rc5 . This can be tested
with CONFIG_SYSCTL. I would really appreciate constructive comments on
this patch series.
Previous version:
https://lore.kernel.org/lkml/20200505153156.925111-1-mic@digikod.net/
[1] https://lore.kernel.org/lkml/1544647356.4028.105.camel@linux.ibm.com/
[2] https://lore.kernel.org/lkml/20190904201933.10736-6-cyphar@cyphar.com/
[3] https://lore.kernel.org/lkml/CALCETrVovr8XNZSroey7pHF46O=kj_c5D9K8h=z2T_cNrpvMig@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CALCETrVeZ0eufFXwfhtaG_j+AdvbzEWE0M3wjXMWVEO7pj+xkw@mail.gmail.com/
[5] https://lore.kernel.org/lkml/20200406221439.1469862-12-deven.desai@linux.microsoft.com/
[6] https://www.python.org/dev/peps/pep-0578/
[7] https://lore.kernel.org/lkml/0c70debd-e79e-d514-06c6-4cd1e021fa8b@python.org/
Regards,
Kees Cook (3):
exec: Change uselib(2) IS_SREG() failure to EACCES
exec: Move S_ISREG() check earlier
exec: Move path_noexec() check earlier
Mickaël Salaün (3):
fs: Introduce O_MAYEXEC flag for openat2(2)
fs,doc: Enable to enforce noexec mounts or file exec through O_MAYEXEC
selftest/openat2: Add tests for O_MAYEXEC enforcing
Mimi Zohar (1):
ima: add policy support for the new file open MAY_OPENEXEC flag
Documentation/ABI/testing/ima_policy | 2 +-
Documentation/admin-guide/sysctl/fs.rst | 45 +++
fs/exec.c | 23 +-
fs/fcntl.c | 2 +-
fs/namei.c | 31 ++-
fs/open.c | 14 +-
include/linux/fcntl.h | 2 +-
include/linux/fs.h | 3 +
include/uapi/asm-generic/fcntl.h | 7 +
kernel/sysctl.c | 12 +-
security/integrity/ima/ima_main.c | 3 +-
security/integrity/ima/ima_policy.c | 15 +-
tools/testing/selftests/kselftest_harness.h | 3 +
tools/testing/selftests/openat2/Makefile | 3 +-
tools/testing/selftests/openat2/config | 1 +
tools/testing/selftests/openat2/helpers.h | 1 +
.../testing/selftests/openat2/omayexec_test.c | 262 ++++++++++++++++++
17 files changed, 400 insertions(+), 29 deletions(-)
create mode 100644 tools/testing/selftests/openat2/config
create mode 100644 tools/testing/selftests/openat2/omayexec_test.c
--
2.27.0
Allow for the enforcement of the O_MAYEXEC openat2(2) flag. Thanks to
the noexec option from the underlying VFS mount, or to the file execute
permission, userspace can enforce these execution policies. This may
allow script interpreters to check execution permission before reading
commands from a file, or dynamic linkers to allow shared object loading.
Add a new sysctl fs.open_mayexec_enforce to enable system administrators
to enforce two complementary security policies according to the
installed system: enforce the noexec mount option, and enforce
executable file permission. Indeed, because of compatibility with
installed systems, only system administrators are able to check that
this new enforcement is in line with the system mount points and file
permissions. A following patch adds documentation.
Being able to restrict execution also enables to protect the kernel by
restricting arbitrary syscalls that an attacker could perform with a
crafted binary or certain script languages. It also improves multilevel
isolation by reducing the ability of an attacker to use side channels
with specific code. These restrictions can natively be enforced for ELF
binaries (with the noexec mount option) but require this kernel
extension to properly handle scripts (e.g., Python, Perl). To get a
consistent execution policy, additional memory restrictions should also
be enforced (e.g. thanks to SELinux).
Because the O_MAYEXEC flag is a meant to enforce a system-wide security
policy (but not application-centric policies), it does not make sense
for userland to check the sysctl value. Indeed, this new flag only
enables to extend the system ability to enforce a policy thanks to (some
trusted) userland collaboration. Moreover, additional security policies
could be managed by LSMs. This is a best-effort approach from the
application developer point of view:
https://lore.kernel.org/lkml/1477d3d7-4b36-afad-7077-a38f42322238@digikod.net/
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Thibaut Sautereau <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kees Cook <redacted>
---
Changes since v5:
* Remove the static enforcement configuration through Kconfig because it
makes the code more simple like this, and because the current sysctl
configuration can only be set with CAP_SYS_ADMIN, the same way mount
options (i.e. noexec) can be set. If an harden distro wants to
enforce a configuration, it should restrict capabilities or sysctl
configuration. Furthermore, an LSM can easily leverage O_MAYEXEC to
fit its need.
* Move checks from inode_permission() to may_open() and make the error
codes more consistent according to file types (in line with a previous
commit): opening a directory with O_MAYEXEC returns EISDIR and other
non-regular file types may return EACCES.
* In may_open(), when OMAYEXEC_ENFORCE_FILE is set, replace explicit
call to generic_permission() with an artificial MAY_EXEC to avoid
double calls. This makes sense especially when an LSM policy forbids
execution of a file.
* Replace the custom proc_omayexec() with
proc_dointvec_minmax_sysadmin(), and then replace the CAP_MAC_ADMIN
check with a CAP_SYS_ADMIN one (suggested by Kees Cook and Stephen
Smalley).
* Use BIT() (suggested by Kees Cook).
* Rename variables (suggested by Kees Cook).
* Reword the kconfig help.
* Import the documentation patch (suggested by Kees Cook):
https://lore.kernel.org/lkml/20200505153156.925111-6-mic@digikod.net/
* Update documentation and add LWN.net article.
Changes since v4:
* Add kernel configuration options to enforce O_MAYEXEC at build time,
and disable the sysctl in such case (requested by James Morris).
* Reword commit message.
Changes since v3:
* Update comment with O_MAYEXEC.
Changes since v2:
* Cosmetic changes.
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()").
---
Documentation/admin-guide/sysctl/fs.rst | 45 +++++++++++++++++++++++++
fs/namei.c | 29 +++++++++++++---
include/linux/fs.h | 1 +
kernel/sysctl.c | 12 +++++--
4 files changed, 80 insertions(+), 7 deletions(-)
@@ -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,50 @@ system needs to prune the inode list instead of allocating more.+open_mayexec_enforce+--------------------++While being ignored by :manpage:`open(2)` and :manpage:`openat(2)`, the+``O_MAYEXEC`` flag can be passed to :manpage:`openat2(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,+or a dynamic linker to only load executable shared objects. One interesting+use case is to enforce a "write xor execute" policy through interpreters.++The ability to restrict code execution must be thought as a system-wide policy,+which first starts by restricting mount points with the ``noexec`` option.+This option is also automatically applied to special filesystems such as /proc+. This prevents files on such mount points to be directly executed by the+kernel or mapped as executable memory (e.g. libraries). With script+interpreters using the ``O_MAYEXEC`` flag, the executable permission can then+be checked before reading commands from files. This makes it possible to+enforce the ``noexec`` at the interpreter level, and thus propagates this+security policy to scripts. To be fully effective, these interpreters also+need to handle the other ways to execute code: command line parameters (e.g.,+option ``-e`` for Perl), module loading (e.g., option ``-m`` for Python),+stdin, file sourcing, environment variables, configuration files, etc.+According to the threat model, it may be acceptable to allow some script+interpreters (e.g. Bash) to interpret commands from stdin, may it be a TTY or a+pipe, because it may not be enough to (directly) perform syscalls.++There are two complementary security policies: enforce the ``noexec`` mount+option, and enforce executable file permission. These policies are handled by+the ``fs.open_mayexec_enforce`` sysctl (writable only with ``CAP_SYS_ADMIN``)+as a bitmask:++1 - Mount restriction: checks that the mount options for the underlying VFS+ mount do not prevent execution.++2 - File permission restriction: checks 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/openat2/omayexec_test.c+and interpreter patches (for the original O_MAYEXEC version) may be found at+https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC .+See also an overview article: https://lwn.net/Articles/820000/ .++ overflowgid & overflowuid -------------------------
@@ -425,10 +426,15 @@ static int sb_permission(struct super_block *sb, struct inode *inode, int mask)return0;}+#define OPEN_MAYEXEC_ENFORCE_MOUNT BIT(0)+#define OPEN_MAYEXEC_ENFORCE_FILE BIT(1)++intsysctl_open_mayexec_enforce__read_mostly;+/***inode_permission-Checkforaccessrightstoagiveninode*@inode:Inodetocheckpermissionon-*@mask:Righttocheckfor(%MAY_READ,%MAY_WRITE,%MAY_EXEC)+*@mask:Righttocheckfor(%MAY_READ,%MAY_WRITE,%MAY_EXEC,%MAY_OPENEXEC)**Checkforread/write/executepermissionsonaninode.Weusefs[ug]idfor*this,lettingussetarbitrarypermissionsforfilesystemaccesswithout
@@ -2849,7 +2855,7 @@ static int may_open(const struct path *path, int acc_mode, int flag)caseS_IFLNK:return-ELOOP;caseS_IFDIR:-if(acc_mode&(MAY_WRITE|MAY_EXEC))+if(acc_mode&(MAY_WRITE|MAY_EXEC|MAY_OPENEXEC))return-EISDIR;break;caseS_IFBLK:
@@ -2859,13 +2865,26 @@ static int may_open(const struct path *path, int acc_mode, int flag)fallthrough;caseS_IFIFO:caseS_IFSOCK:-if(acc_mode&MAY_EXEC)+if(acc_mode&(MAY_EXEC|MAY_OPENEXEC))return-EACCES;flag&=~O_TRUNC;break;caseS_IFREG:-if((acc_mode&MAY_EXEC)&&path_noexec(path))-return-EACCES;+if(path_noexec(path)){+if(acc_mode&MAY_EXEC)+return-EACCES;+if((acc_mode&MAY_OPENEXEC)&&+(sysctl_open_mayexec_enforce&OPEN_MAYEXEC_ENFORCE_MOUNT))+return-EACCES;+}+if((acc_mode&MAY_OPENEXEC)&&+(sysctl_open_mayexec_enforce&OPEN_MAYEXEC_ENFORCE_FILE))+/*+*Becauseacc_modemaychangehere,thenextandonly+*useofacc_modeshouldthenbebythefollowingcall+*toinode_permission().+*/+acc_mode|=MAY_EXEC;break;}
Test propagation of noexec mount points or file executability through
files open with or without O_MAYEXEC, thanks to the
fs.open_mayexec_enforce sysctl.
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Thibaut Sautereau <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <redacted>
Cc: Shuah Khan <shuah@kernel.org>
---
Changes since v5:
* Refactor with FIXTURE_VARIANT, which make the tests much more easy to
read and maintain.
* Save and restore initial sysctl value (suggested by Kees Cook).
* Test with a sysctl value of 0.
* Check errno in sysctl_access_write test.
* Update tests for the CAP_SYS_ADMIN switch.
* Update tests to check -EISDIR (replacing -EACCES).
* Replace FIXTURE_DATA() with FIXTURE() (spotted by Kees Cook).
* Use global const strings.
Changes since v3:
* Replace RESOLVE_MAYEXEC with O_MAYEXEC.
* Add tests to check that O_MAYEXEC is ignored by open(2) and openat(2).
Changes since v2:
* Move tests from exec/ to openat2/ .
* Replace O_MAYEXEC with RESOLVE_MAYEXEC from openat2(2).
* Cleanup tests.
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.
---
tools/testing/selftests/kselftest_harness.h | 3 +
tools/testing/selftests/openat2/Makefile | 3 +-
tools/testing/selftests/openat2/config | 1 +
tools/testing/selftests/openat2/helpers.h | 1 +
.../testing/selftests/openat2/omayexec_test.c | 262 ++++++++++++++++++
5 files changed, 269 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/openat2/config
create mode 100644 tools/testing/selftests/openat2/omayexec_test.c
From: Mimi Zohar <zohar@linux.ibm.com>
The kernel has no way of differentiating between a file containing data
or code being opened by an interpreter. The proposed O_MAYEXEC
openat2(2) flag bridges this gap by defining and enabling the
MAY_OPENEXEC flag.
This patch adds IMA policy support for the new MAY_OPENEXEC flag.
Example:
measure func=FILE_CHECK mask=^MAY_OPENEXEC
appraise func=FILE_CHECK appraise_type=imasig mask=^MAY_OPENEXEC
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Lakshmi Ramasubramanian <redacted>
Acked-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/1588167523-7866-3-git-send-email-zohar@linux.ibm.com
---
Documentation/ABI/testing/ima_policy | 2 +-
security/integrity/ima/ima_main.c | 3 ++-
security/integrity/ima/ima_policy.c | 15 +++++++++++----
3 files changed, 14 insertions(+), 6 deletions(-)
@@ -490,7 +490,8 @@ int ima_file_check(struct file *file, int mask)security_task_getsecid(current,&secid);returnprocess_measurement(file,current_cred(),secid,NULL,0,-mask&(MAY_READ|MAY_WRITE|MAY_EXEC|+mask&(MAY_READ|MAY_WRITE|+MAY_EXEC|MAY_OPENEXEC|MAY_APPEND),FILE_CHECK);}EXPORT_SYMBOL_GPL(ima_file_check);
From: Kees Cook <redacted>
The execve(2)/uselib(2) syscalls have always rejected non-regular
files. Recently, it was noticed that a deadlock was introduced when trying
to execute pipes, as the S_ISREG() test was happening too late. This was
fixed in commit 73601ea5b7b1 ("fs/open.c: allow opening only regular files
during execve()"), but it was added after inode_permission() had already
run, which meant LSMs could see bogus attempts to execute non-regular
files.
Move the test into the other inode type checks (which already look
for other pathological conditions[1]). Since there is no need to use
FMODE_EXEC while we still have access to "acc_mode", also switch the
test to MAY_EXEC.
Also include a comment with the redundant S_ISREG() checks at the end of
execve(2)/uselib(2) to note that they are present to avoid any mistakes.
My notes on the call path, and related arguments, checks, etc:
do_open_execat()
struct open_flags open_exec_flags = {
.open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC,
.acc_mode = MAY_EXEC,
...
do_filp_open(dfd, filename, open_flags)
path_openat(nameidata, open_flags, flags)
file = alloc_empty_file(open_flags, current_cred());
do_open(nameidata, file, open_flags)
may_open(path, acc_mode, open_flag)
/* new location of MAY_EXEC vs S_ISREG() test */
inode_permission(inode, MAY_OPEN | acc_mode)
security_inode_permission(inode, acc_mode)
vfs_open(path, file)
do_dentry_open(file, path->dentry->d_inode, open)
/* old location of FMODE_EXEC vs S_ISREG() test */
security_file_open(f)
open()
[1] https://lore.kernel.org/lkml/202006041910.9EF0C602@keescook/
Signed-off-by: Kees Cook <redacted>
Acked-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20200605160013.3954297-3-keescook@chromium.org
---
fs/exec.c | 14 ++++++++++++--
fs/namei.c | 6 ++++--
fs/open.c | 6 ------
3 files changed, 16 insertions(+), 10 deletions(-)
@@ -2849,16 +2849,18 @@ static int may_open(const struct path *path, int acc_mode, int flag)caseS_IFLNK:return-ELOOP;caseS_IFDIR:-if(acc_mode&MAY_WRITE)+if(acc_mode&(MAY_WRITE|MAY_EXEC))return-EISDIR;break;caseS_IFBLK:caseS_IFCHR:if(!may_open_dev(path))return-EACCES;-/*FALLTHRU*/+fallthrough;caseS_IFIFO:caseS_IFSOCK:+if(acc_mode&MAY_EXEC)+return-EACCES;flag&=~O_TRUNC;break;}
@@ -784,12 +784,6 @@ static int do_dentry_open(struct file *f,return0;}-/* Any file opened for execve()/uselib() has to be a regular file. */-if(unlikely(f->f_flags&FMODE_EXEC&&!S_ISREG(inode->i_mode))){-error=-EACCES;-gotocleanup_file;-}-if(f->f_mode&FMODE_WRITE&&!special_file(inode->i_mode)){error=get_write_access(inode);if(unlikely(error))
From: Kees Cook <redacted>
The path_noexec() check, like the regular file check, was happening too
late, letting LSMs see impossible execve()s. Check it earlier as well
in may_open() and collect the redundant fs/exec.c path_noexec() test
under the same robustness comment as the S_ISREG() check.
My notes on the call path, and related arguments, checks, etc:
do_open_execat()
struct open_flags open_exec_flags = {
.open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC,
.acc_mode = MAY_EXEC,
...
do_filp_open(dfd, filename, open_flags)
path_openat(nameidata, open_flags, flags)
file = alloc_empty_file(open_flags, current_cred());
do_open(nameidata, file, open_flags)
may_open(path, acc_mode, open_flag)
/* new location of MAY_EXEC vs path_noexec() test */
inode_permission(inode, MAY_OPEN | acc_mode)
security_inode_permission(inode, acc_mode)
vfs_open(path, file)
do_dentry_open(file, path->dentry->d_inode, open)
security_file_open(f)
open()
/* old location of path_noexec() test */
Signed-off-by: Kees Cook <redacted>
Acked-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20200605160013.3954297-4-keescook@chromium.org
---
fs/exec.c | 12 ++++--------
fs/namei.c | 4 ++++
2 files changed, 8 insertions(+), 8 deletions(-)
@@ -2863,6 +2863,10 @@ static int may_open(const struct path *path, int acc_mode, int flag)return-EACCES;flag&=~O_TRUNC;break;+caseS_IFREG:+if((acc_mode&MAY_EXEC)&&path_noexec(path))+return-EACCES;+break;}error=inode_permission(inode,MAY_OPEN|acc_mode);
When the O_MAYEXEC flag is passed, openat2(2) may be subject to
additional restrictions depending on a security policy managed by the
kernel through a sysctl or implemented by an LSM thanks to the
inode_permission hook. This new flag is ignored by open(2) and
openat(2) because of their unspecified flags handling.
The underlying idea is to be able to restrict scripts interpretation
according to a policy defined by the system administrator. For this to
be possible, script interpreters must use the O_MAYEXEC flag
appropriately. To be fully effective, these interpreters also need to
handle the other ways to execute code: command line parameters (e.g.,
option -e for Perl), module loading (e.g., option -m for Python), stdin,
file sourcing, environment variables, configuration files, etc.
According to the threat model, it may be acceptable to allow some script
interpreters (e.g. Bash) to interpret commands from stdin, may it be a
TTY or a pipe, because it may not be enough to (directly) perform
syscalls. Further documentation can be found in a following patch.
Even without enforced security policy, userland interpreters can set it
to enforce the system policy at their level, knowing that it will not
break anything on running systems which do not care about this feature.
However, on systems which want this feature enforced, there will be
knowledgeable people (i.e. sysadmins who enforced O_MAYEXEC
deliberately) to manage it. A simple security policy implementation,
configured through a dedicated sysctl, is available in a following
patch.
O_MAYEXEC should not be confused with the O_EXEC flag which is intended
for execute-only, which obviously doesn't work for scripts. However, a
similar behavior could be implemented in userland with O_PATH:
https://lore.kernel.org/lkml/1e2f6913-42f2-3578-28ed-567f6a4bdda1@digikod.net/
The implementation of O_MAYEXEC almost duplicates what execve(2) and
uselib(2) are already doing: setting MAY_OPENEXEC in acc_mode (which can
then be checked as MAY_EXEC, if enforced), and propagating FMODE_EXEC to
_fmode via __FMODE_EXEC flag (which can then trigger a
fanotify/FAN_OPEN_EXEC event).
This is an updated subset of the patch initially written by Vincent
Strubel for CLIP OS 4:
https://github.com/clipos-archive/src_platform_clip-patches/blob/f5cb330d6b684752e403b4e41b39f7004d88e561/1901_open_mayexec.patch
This patch has been used for more than 12 years with customized script
interpreters. Some examples (with the original name O_MAYEXEC) can be
found here:
https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
Co-developed-by: Vincent Strubel <redacted>
Signed-off-by: Vincent Strubel <redacted>
Co-developed-by: Thibaut Sautereau <redacted>
Signed-off-by: Thibaut Sautereau <redacted>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Deven Bowers <redacted>
Reviewed-by: Kees Cook <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
---
Changes since v5:
* Update commit message.
Changes since v3:
* Switch back to O_MAYEXEC, but only handle it with openat2(2) which
checks unknown flags (suggested by Aleksa Sarai). Cf.
https://lore.kernel.org/lkml/20200430015429.wuob7m5ofdewubui@yavin.dot.cyphar.com/
Changes since v2:
* Replace O_MAYEXEC with RESOLVE_MAYEXEC from openat2(2). This change
enables to not break existing application using bogus O_* flags that
may be ignored by current kernels by using a new dedicated flag, only
usable through openat2(2) (suggested by Jeff Layton). Using this flag
will results in an error if the running kernel does not support it.
User space needs to manage this case, as with other RESOLVE_* flags.
The best effort approach to security (for most common distros) will
simply consists of ignoring such an error and retry without
RESOLVE_MAYEXEC. However, a fully controlled system may which to
error out if such an inconsistency is detected.
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):
https://lore.kernel.org/lkml/20181213094658.GA996@lithium.mbobrowski.org/
---
fs/fcntl.c | 2 +-
fs/open.c | 8 ++++++++
include/linux/fcntl.h | 2 +-
include/linux/fs.h | 2 ++
include/uapi/asm-generic/fcntl.h | 7 +++++++
5 files changed, 19 insertions(+), 2 deletions(-)
@@ -1033,7 +1033,7 @@ static int __init fcntl_init(void)*Exceptions:O_NONBLOCKisatwobitdefineonparisc;O_NDELAY*isdefinedasO_NONBLOCKonsomeplatformsandnotonothers.*/-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));
@@ -10,7 +10,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)/* List of all valid flags for the how->upgrade_mask argument: */#define VALID_UPGRADE_FLAGS \
@@ -101,6 +101,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/**flagsinfile.f_mode.NotethatFMODE_READandFMODE_WRITEmustcorrespond
Reviewed-by: Randy Dunlap <redacted>
with one tiny nit:
quoted hunk
@@ -165,6 +166,50 @@ system needs to prune the inode list instead of allocating+The ability to restrict code execution must be thought as a system-wide policy,+which first starts by restricting mount points with the ``noexec`` option.+This option is also automatically applied to special filesystems such as /proc+. This prevents files on such mount points to be directly executed by the
Can you move that period from the beginning of the line to the end of the
previous line?
+kernel or mapped as executable memory (e.g. libraries). With script
+interpreters using the ``O_MAYEXEC`` flag, the executable permission can then
+be checked before reading commands from files. This makes it possible to
+enforce the ``noexec`` at the interpreter level, and thus propagates this
+security policy to scripts. To be fully effective, these interpreters also
+need to handle the other ways to execute code: command line parameters (e.g.,
+option ``-e`` for Perl), module loading (e.g., option ``-m`` for Python),
+stdin, file sourcing, environment variables, configuration files, etc.
+According to the threat model, it may be acceptable to allow some script
+interpreters (e.g. Bash) to interpret commands from stdin, may it be a TTY or a
+pipe, because it may not be enough to (directly) perform syscalls.
On Tue, Jul 14, 2020 at 08:16:35PM +0200, Mickaël Salaün wrote:
quoted hunk
When the O_MAYEXEC flag is passed, openat2(2) may be subject to
additional restrictions depending on a security policy managed by the
kernel through a sysctl or implemented by an LSM thanks to the
inode_permission hook. This new flag is ignored by open(2) and
openat(2) because of their unspecified flags handling.
The underlying idea is to be able to restrict scripts interpretation
according to a policy defined by the system administrator. For this to
be possible, script interpreters must use the O_MAYEXEC flag
appropriately. To be fully effective, these interpreters also need to
handle the other ways to execute code: command line parameters (e.g.,
option -e for Perl), module loading (e.g., option -m for Python), stdin,
file sourcing, environment variables, configuration files, etc.
According to the threat model, it may be acceptable to allow some script
interpreters (e.g. Bash) to interpret commands from stdin, may it be a
TTY or a pipe, because it may not be enough to (directly) perform
syscalls. Further documentation can be found in a following patch.
Even without enforced security policy, userland interpreters can set it
to enforce the system policy at their level, knowing that it will not
break anything on running systems which do not care about this feature.
However, on systems which want this feature enforced, there will be
knowledgeable people (i.e. sysadmins who enforced O_MAYEXEC
deliberately) to manage it. A simple security policy implementation,
configured through a dedicated sysctl, is available in a following
patch.
O_MAYEXEC should not be confused with the O_EXEC flag which is intended
for execute-only, which obviously doesn't work for scripts. However, a
similar behavior could be implemented in userland with O_PATH:
https://lore.kernel.org/lkml/1e2f6913-42f2-3578-28ed-567f6a4bdda1@digikod.net/
The implementation of O_MAYEXEC almost duplicates what execve(2) and
uselib(2) are already doing: setting MAY_OPENEXEC in acc_mode (which can
then be checked as MAY_EXEC, if enforced), and propagating FMODE_EXEC to
_fmode via __FMODE_EXEC flag (which can then trigger a
fanotify/FAN_OPEN_EXEC event).
This is an updated subset of the patch initially written by Vincent
Strubel for CLIP OS 4:
https://github.com/clipos-archive/src_platform_clip-patches/blob/f5cb330d6b684752e403b4e41b39f7004d88e561/1901_open_mayexec.patch
This patch has been used for more than 12 years with customized script
interpreters. Some examples (with the original name O_MAYEXEC) can be
found here:
https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
Co-developed-by: Vincent Strubel <redacted>
Signed-off-by: Vincent Strubel <redacted>
Co-developed-by: Thibaut Sautereau <redacted>
Signed-off-by: Thibaut Sautereau <redacted>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Deven Bowers <redacted>
Reviewed-by: Kees Cook <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
---
Changes since v5:
* Update commit message.
Changes since v3:
* Switch back to O_MAYEXEC, but only handle it with openat2(2) which
checks unknown flags (suggested by Aleksa Sarai). Cf.
https://lore.kernel.org/lkml/20200430015429.wuob7m5ofdewubui@yavin.dot.cyphar.com/
Changes since v2:
* Replace O_MAYEXEC with RESOLVE_MAYEXEC from openat2(2). This change
enables to not break existing application using bogus O_* flags that
may be ignored by current kernels by using a new dedicated flag, only
usable through openat2(2) (suggested by Jeff Layton). Using this flag
will results in an error if the running kernel does not support it.
User space needs to manage this case, as with other RESOLVE_* flags.
The best effort approach to security (for most common distros) will
simply consists of ignoring such an error and retry without
RESOLVE_MAYEXEC. However, a fully controlled system may which to
error out if such an inconsistency is detected.
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):
https://lore.kernel.org/lkml/20181213094658.GA996@lithium.mbobrowski.org/
---
fs/fcntl.c | 2 +-
fs/open.c | 8 ++++++++
include/linux/fcntl.h | 2 +-
include/linux/fs.h | 2 ++
include/uapi/asm-generic/fcntl.h | 7 +++++++
5 files changed, 19 insertions(+), 2 deletions(-)
@@ -1033,7 +1033,7 @@ static int __init fcntl_init(void)*Exceptions:O_NONBLOCKisatwobitdefineonparisc;O_NDELAY*isdefinedasO_NONBLOCKonsomeplatformsandnotonothers.*/-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));
@@ -987,6 +987,8 @@ inline struct open_how build_open_how(int flags, umode_t mode).mode=mode&S_IALLUGO,};+/* O_MAYEXEC is ignored by syscalls relying on build_open_how(). */+how.flags&=~O_MAYEXEC;/* O_PATH beats everything else. */if(how.flags&O_PATH)how.flags&=O_PATH_FLAGS;
@@ -1054,6 +1056,12 @@ inline int build_open_flags(const struct open_how *how, struct open_flags *op)if(flags&__O_SYNC)flags|=O_DSYNC;+/* Checks execution permissions on open. */+if(flags&O_MAYEXEC){+acc_mode|=MAY_OPENEXEC;+flags|=__FMODE_EXEC;+}
Adding __FMODE_EXEC here will immediately change the behaviors of NFS
and fsnotify. If that's going to happen, I think it needs to be under
the control of the later patches doing the behavioral controls.
(specifically, NFS looks like it completely changes its access control
test when this is set and ignores the read/write checks entirely, which
is not what's wanted).
--
Kees Cook
On Tue, Jul 14, 2020 at 08:16:36PM +0200, Mickaël Salaün wrote:
quoted hunk
@@ -2849,7 +2855,7 @@ static int may_open(const struct path *path, int acc_mode, int flag) case S_IFLNK: return -ELOOP; case S_IFDIR:- if (acc_mode & (MAY_WRITE | MAY_EXEC))+ if (acc_mode & (MAY_WRITE | MAY_EXEC | MAY_OPENEXEC)) return -EISDIR; break;
(I need to figure out where "open for reading" rejects S_IFDIR, since
it's clearly not here...)
quoted hunk
case S_IFBLK:
@@ -2859,13 +2865,26 @@ static int may_open(const struct path *path, int acc_mode, int flag) fallthrough; case S_IFIFO: case S_IFSOCK:- if (acc_mode & MAY_EXEC)+ if (acc_mode & (MAY_EXEC | MAY_OPENEXEC)) return -EACCES; flag &= ~O_TRUNC; break;
This will immediately break a system that runs code with MAY_OPENEXEC
set but reads from a block, char, fifo, or socket, even in the case of
a sysadmin leaving the "file" sysctl disabled.
case S_IFREG:
- if ((acc_mode & MAY_EXEC) && path_noexec(path))
- return -EACCES;
+ if (path_noexec(path)) {
+ if (acc_mode & MAY_EXEC)
+ return -EACCES;
+ if ((acc_mode & MAY_OPENEXEC) &&
+ (sysctl_open_mayexec_enforce & OPEN_MAYEXEC_ENFORCE_MOUNT))
+ return -EACCES;
+ }
+ if ((acc_mode & MAY_OPENEXEC) &&
+ (sysctl_open_mayexec_enforce & OPEN_MAYEXEC_ENFORCE_FILE))
+ /*
+ * Because acc_mode may change here, the next and only
+ * use of acc_mode should then be by the following call
+ * to inode_permission().
+ */
+ acc_mode |= MAY_EXEC;
break;
}
Likely very minor, but I'd like to avoid the path_noexec() call in the
fast-path (it dereferences a couple pointers where as doing bit tests on
acc_mode is fast).
Given that and the above observations, I think that may_open() likely
needs to start with:
if (acc_mode & MAY_OPENEXEC) {
/* Reject all file types when mount enforcement set. */
if ((sysctl_open_mayexec_enforce & OPEN_MAYEXEC_ENFORCE_MOUNT) &&
path_noexec(path))
return -EACCES;
/* Treat the same as MAY_EXEC. */
if (sysctl_open_mayexec_enforce & OPEN_MAYEXEC_ENFORCE_FILE))
acc_mode |= MAY_EXEC;
}
(Though I'm not 100% sure that path_noexec() is safe to be called for
all file types: i.e. path->mnt and path->-mnt->mnt_sb *always* non-NULL?)
This change would also imply that OPEN_MAYEXEC_ENFORCE_FILE *includes*
OPEN_MAYEXEC_ENFORCE_MOUNT (i.e. the sysctl should not be a bitfield),
since path_noexec() would get checked for S_ISREG. I can't come up with
a rationale where one would want OPEN_MAYEXEC_ENFORCE_FILE but _not_
OPEN_MAYEXEC_ENFORCE_MOUNT?
(I can absolutely see wanting only OPEN_MAYEXEC_ENFORCE_MOUNT, or
suddenly one has to go mark every loaded thing with the exec bit and
most distros haven't done this to, for example, shared libraries. But
setting the exec bit and then NOT wanting to enforce the mount check
seems... not sensible?)
Outside of this change, yes, I like this now -- it's much cleaner
because we have all the checks in the same place where they belong. :)
@@ -113,6 +113,7 @@ static int sixty = 60;staticint__maybe_unusedneg_one=-1;staticint__maybe_unusedtwo=2;+staticint__maybe_unusedthree=3;staticint__maybe_unusedfour=4;staticunsignedlongzero_ul;staticunsignedlongone_ul=1;
Oh, are these still here? I thought they got removed (or at least made
const). Where did that series go? Hmpf, see sysctl_vals, but yes, for
now, this is fine.
quoted hunk
@@ -888,7 +889,6 @@ static int proc_taint(struct ctl_table *table, int write, return err; }-#ifdef CONFIG_PRINTK static int proc_dointvec_minmax_sysadmin(struct ctl_table *table, int write, void *buffer, size_t *lenp, loff_t *ppos) {
@@ -897,7 +897,6 @@ static int proc_dointvec_minmax_sysadmin(struct ctl_table *table, int write, return proc_dointvec_minmax(table, write, buffer, lenp, ppos); }-#endif /** * struct do_proc_dointvec_minmax_conv_param - proc_dointvec_minmax() range checking structure
On Tue, Jul 14, 2020 at 08:16:37PM +0200, Mickaël Salaün wrote:
Test propagation of noexec mount points or file executability through
files open with or without O_MAYEXEC, thanks to the
fs.open_mayexec_enforce sysctl.
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Thibaut Sautereau <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <redacted>
Cc: Shuah Khan <shuah@kernel.org>
Yay variants! :)
Reviewed-by: Kees Cook <redacted>
--
Kees Cook
On Tue, Jul 14, 2020 at 08:16:38PM +0200, Mickaël Salaün wrote:
From: Mimi Zohar <zohar@linux.ibm.com>
The kernel has no way of differentiating between a file containing data
or code being opened by an interpreter. The proposed O_MAYEXEC
openat2(2) flag bridges this gap by defining and enabling the
MAY_OPENEXEC flag.
This patch adds IMA policy support for the new MAY_OPENEXEC flag.
Example:
measure func=FILE_CHECK mask=^MAY_OPENEXEC
appraise func=FILE_CHECK appraise_type=imasig mask=^MAY_OPENEXEC
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Lakshmi Ramasubramanian <redacted>
Acked-by: Mickaël Salaün <mic@digikod.net>
(Process nit: if you're sending this on behalf of another author, then
this should be Signed-off-by rather than Acked-by.)
--
Kees Cook
On Tue, Jul 14, 2020 at 08:16:35PM +0200, Mickaël Salaün wrote:
quoted
When the O_MAYEXEC flag is passed, openat2(2) may be subject to
additional restrictions depending on a security policy managed by the
kernel through a sysctl or implemented by an LSM thanks to the
inode_permission hook. This new flag is ignored by open(2) and
openat(2) because of their unspecified flags handling.
The underlying idea is to be able to restrict scripts interpretation
according to a policy defined by the system administrator. For this to
be possible, script interpreters must use the O_MAYEXEC flag
appropriately. To be fully effective, these interpreters also need to
handle the other ways to execute code: command line parameters (e.g.,
option -e for Perl), module loading (e.g., option -m for Python), stdin,
file sourcing, environment variables, configuration files, etc.
According to the threat model, it may be acceptable to allow some script
interpreters (e.g. Bash) to interpret commands from stdin, may it be a
TTY or a pipe, because it may not be enough to (directly) perform
syscalls. Further documentation can be found in a following patch.
Even without enforced security policy, userland interpreters can set it
to enforce the system policy at their level, knowing that it will not
break anything on running systems which do not care about this feature.
However, on systems which want this feature enforced, there will be
knowledgeable people (i.e. sysadmins who enforced O_MAYEXEC
deliberately) to manage it. A simple security policy implementation,
configured through a dedicated sysctl, is available in a following
patch.
O_MAYEXEC should not be confused with the O_EXEC flag which is intended
for execute-only, which obviously doesn't work for scripts. However, a
similar behavior could be implemented in userland with O_PATH:
https://lore.kernel.org/lkml/1e2f6913-42f2-3578-28ed-567f6a4bdda1@digikod.net/
The implementation of O_MAYEXEC almost duplicates what execve(2) and
uselib(2) are already doing: setting MAY_OPENEXEC in acc_mode (which can
then be checked as MAY_EXEC, if enforced), and propagating FMODE_EXEC to
_fmode via __FMODE_EXEC flag (which can then trigger a
fanotify/FAN_OPEN_EXEC event).
This is an updated subset of the patch initially written by Vincent
Strubel for CLIP OS 4:
https://github.com/clipos-archive/src_platform_clip-patches/blob/f5cb330d6b684752e403b4e41b39f7004d88e561/1901_open_mayexec.patch
This patch has been used for more than 12 years with customized script
interpreters. Some examples (with the original name O_MAYEXEC) can be
found here:
https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
Co-developed-by: Vincent Strubel <redacted>
Signed-off-by: Vincent Strubel <redacted>
Co-developed-by: Thibaut Sautereau <redacted>
Signed-off-by: Thibaut Sautereau <redacted>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Deven Bowers <redacted>
Reviewed-by: Kees Cook <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
---
Changes since v5:
* Update commit message.
Changes since v3:
* Switch back to O_MAYEXEC, but only handle it with openat2(2) which
checks unknown flags (suggested by Aleksa Sarai). Cf.
https://lore.kernel.org/lkml/20200430015429.wuob7m5ofdewubui@yavin.dot.cyphar.com/
Changes since v2:
* Replace O_MAYEXEC with RESOLVE_MAYEXEC from openat2(2). This change
enables to not break existing application using bogus O_* flags that
may be ignored by current kernels by using a new dedicated flag, only
usable through openat2(2) (suggested by Jeff Layton). Using this flag
will results in an error if the running kernel does not support it.
User space needs to manage this case, as with other RESOLVE_* flags.
The best effort approach to security (for most common distros) will
simply consists of ignoring such an error and retry without
RESOLVE_MAYEXEC. However, a fully controlled system may which to
error out if such an inconsistency is detected.
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):
https://lore.kernel.org/lkml/20181213094658.GA996@lithium.mbobrowski.org/
---
fs/fcntl.c | 2 +-
fs/open.c | 8 ++++++++
include/linux/fcntl.h | 2 +-
include/linux/fs.h | 2 ++
include/uapi/asm-generic/fcntl.h | 7 +++++++
5 files changed, 19 insertions(+), 2 deletions(-)
@@ -1033,7 +1033,7 @@ static int __init fcntl_init(void)*Exceptions:O_NONBLOCKisatwobitdefineonparisc;O_NDELAY*isdefinedasO_NONBLOCKonsomeplatformsandnotonothers.*/-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));
@@ -987,6 +987,8 @@ inline struct open_how build_open_how(int flags, umode_t mode).mode=mode&S_IALLUGO,};+/* O_MAYEXEC is ignored by syscalls relying on build_open_how(). */+how.flags&=~O_MAYEXEC;/* O_PATH beats everything else. */if(how.flags&O_PATH)how.flags&=O_PATH_FLAGS;
@@ -1054,6 +1056,12 @@ inline int build_open_flags(const struct open_how *how, struct open_flags *op)if(flags&__O_SYNC)flags|=O_DSYNC;+/* Checks execution permissions on open. */+if(flags&O_MAYEXEC){+acc_mode|=MAY_OPENEXEC;+flags|=__FMODE_EXEC;+}
Adding __FMODE_EXEC here will immediately change the behaviors of NFS
and fsnotify. If that's going to happen, I think it needs to be under
the control of the later patches doing the behavioral controls.
(specifically, NFS looks like it completely changes its access control
test when this is set and ignores the read/write checks entirely, which
is not what's wanted).
On Tue, Jul 14, 2020 at 08:16:36PM +0200, Mickaël Salaün wrote:
quoted
@@ -2849,7 +2855,7 @@ static int may_open(const struct path *path, int acc_mode, int flag) case S_IFLNK: return -ELOOP; case S_IFDIR:- if (acc_mode & (MAY_WRITE | MAY_EXEC))+ if (acc_mode & (MAY_WRITE | MAY_EXEC | MAY_OPENEXEC)) return -EISDIR; break;
(I need to figure out where "open for reading" rejects S_IFDIR, since
it's clearly not here...)
quoted
case S_IFBLK:
@@ -2859,13 +2865,26 @@ static int may_open(const struct path *path, int acc_mode, int flag) fallthrough; case S_IFIFO: case S_IFSOCK:- if (acc_mode & MAY_EXEC)+ if (acc_mode & (MAY_EXEC | MAY_OPENEXEC)) return -EACCES; flag &= ~O_TRUNC; break;
This will immediately break a system that runs code with MAY_OPENEXEC
set but reads from a block, char, fifo, or socket, even in the case of
a sysadmin leaving the "file" sysctl disabled.
As documented, O_MAYEXEC is for regular files. The only legitimate use
case seems to be with pipes, which should probably be allowed when
enforcement is disabled.
quoted
case S_IFREG:
- if ((acc_mode & MAY_EXEC) && path_noexec(path))
- return -EACCES;
+ if (path_noexec(path)) {
+ if (acc_mode & MAY_EXEC)
+ return -EACCES;
+ if ((acc_mode & MAY_OPENEXEC) &&
+ (sysctl_open_mayexec_enforce & OPEN_MAYEXEC_ENFORCE_MOUNT))
+ return -EACCES;
+ }
+ if ((acc_mode & MAY_OPENEXEC) &&
+ (sysctl_open_mayexec_enforce & OPEN_MAYEXEC_ENFORCE_FILE))
+ /*
+ * Because acc_mode may change here, the next and only
+ * use of acc_mode should then be by the following call
+ * to inode_permission().
+ */
+ acc_mode |= MAY_EXEC;
break;
}
Likely very minor, but I'd like to avoid the path_noexec() call in the
fast-path (it dereferences a couple pointers where as doing bit tests on
acc_mode is fast).
Given that and the above observations, I think that may_open() likely
needs to start with:
if (acc_mode & MAY_OPENEXEC) {
/* Reject all file types when mount enforcement set. */
if ((sysctl_open_mayexec_enforce & OPEN_MAYEXEC_ENFORCE_MOUNT) &&
path_noexec(path))
return -EACCES;
/* Treat the same as MAY_EXEC. */
if (sysctl_open_mayexec_enforce & OPEN_MAYEXEC_ENFORCE_FILE))
acc_mode |= MAY_EXEC;
}
OK
(Though I'm not 100% sure that path_noexec() is safe to be called for
all file types: i.e. path->mnt and path->-mnt->mnt_sb *always* non-NULL?)
This change would also imply that OPEN_MAYEXEC_ENFORCE_FILE *includes*
OPEN_MAYEXEC_ENFORCE_MOUNT (i.e. the sysctl should not be a bitfield),
since path_noexec() would get checked for S_ISREG. I can't come up with
a rationale where one would want OPEN_MAYEXEC_ENFORCE_FILE but _not_
OPEN_MAYEXEC_ENFORCE_MOUNT?
I don't see why it is an inclusion.
(I can absolutely see wanting only OPEN_MAYEXEC_ENFORCE_MOUNT, or
suddenly one has to go mark every loaded thing with the exec bit and
most distros haven't done this to, for example, shared libraries. But
setting the exec bit and then NOT wanting to enforce the mount check
seems... not sensible?)
Outside of this change, yes, I like this now -- it's much cleaner
because we have all the checks in the same place where they belong. :)
@@ -113,6 +113,7 @@ static int sixty = 60;staticint__maybe_unusedneg_one=-1;staticint__maybe_unusedtwo=2;+staticint__maybe_unusedthree=3;staticint__maybe_unusedfour=4;staticunsignedlongzero_ul;staticunsignedlongone_ul=1;
Oh, are these still here? I thought they got removed (or at least made
const). Where did that series go? Hmpf, see sysctl_vals, but yes, for
now, this is fine.
quoted
@@ -888,7 +889,6 @@ static int proc_taint(struct ctl_table *table, int write, return err; }-#ifdef CONFIG_PRINTK static int proc_dointvec_minmax_sysadmin(struct ctl_table *table, int write, void *buffer, size_t *lenp, loff_t *ppos) {
@@ -897,7 +897,6 @@ static int proc_dointvec_minmax_sysadmin(struct ctl_table *table, int write, return proc_dointvec_minmax(table, write, buffer, lenp, ppos); }-#endif /** * struct do_proc_dointvec_minmax_conv_param - proc_dointvec_minmax() range checking structure
On Tue, Jul 14, 2020 at 08:16:38PM +0200, Mickaël Salaün wrote:
quoted
From: Mimi Zohar <zohar@linux.ibm.com>
The kernel has no way of differentiating between a file containing data
or code being opened by an interpreter. The proposed O_MAYEXEC
openat2(2) flag bridges this gap by defining and enabling the
MAY_OPENEXEC flag.
This patch adds IMA policy support for the new MAY_OPENEXEC flag.
Example:
measure func=FILE_CHECK mask=^MAY_OPENEXEC
appraise func=FILE_CHECK appraise_type=imasig mask=^MAY_OPENEXEC
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Lakshmi Ramasubramanian <redacted>
Acked-by: Mickaël Salaün <mic@digikod.net>
(Process nit: if you're sending this on behalf of another author, then
this should be Signed-off-by rather than Acked-by.)
Reviewed-by: Randy Dunlap <redacted>
with one tiny nit:
quoted
@@ -165,6 +166,50 @@ system needs to prune the inode list instead of allocating+The ability to restrict code execution must be thought as a system-wide policy,+which first starts by restricting mount points with the ``noexec`` option.+This option is also automatically applied to special filesystems such as /proc+. This prevents files on such mount points to be directly executed by the
Can you move that period from the beginning of the line to the end of the
previous line?
OK, done. Thanks!
quoted
+kernel or mapped as executable memory (e.g. libraries). With script
+interpreters using the ``O_MAYEXEC`` flag, the executable permission can then
+be checked before reading commands from files. This makes it possible to
+enforce the ``noexec`` at the interpreter level, and thus propagates this
+security policy to scripts. To be fully effective, these interpreters also
+need to handle the other ways to execute code: command line parameters (e.g.,
+option ``-e`` for Perl), module loading (e.g., option ``-m`` for Python),
+stdin, file sourcing, environment variables, configuration files, etc.
+According to the threat model, it may be acceptable to allow some script
+interpreters (e.g. Bash) to interpret commands from stdin, may it be a TTY or a
+pipe, because it may not be enough to (directly) perform syscalls.
From: Randy Dunlap <hidden> Date: 2020-07-16 14:59:44
On 7/16/20 7:40 AM, Mickaël Salaün wrote:
On 15/07/2020 22:40, Kees Cook wrote:
quoted
On Tue, Jul 14, 2020 at 08:16:38PM +0200, Mickaël Salaün wrote:
quoted
From: Mimi Zohar <zohar@linux.ibm.com>
The kernel has no way of differentiating between a file containing data
or code being opened by an interpreter. The proposed O_MAYEXEC
openat2(2) flag bridges this gap by defining and enabling the
MAY_OPENEXEC flag.
This patch adds IMA policy support for the new MAY_OPENEXEC flag.
Example:
measure func=FILE_CHECK mask=^MAY_OPENEXEC
appraise func=FILE_CHECK appraise_type=imasig mask=^MAY_OPENEXEC
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Lakshmi Ramasubramanian <redacted>
Acked-by: Mickaël Salaün <mic@digikod.net>
(Process nit: if you're sending this on behalf of another author, then
this should be Signed-off-by rather than Acked-by.)
I'm not a co-author of this patch.
from Documentation/process/submitting-patches.rst:
The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--
~Randy
On Tue, Jul 14, 2020 at 08:16:38PM +0200, Mickaël Salaün wrote:
quoted
From: Mimi Zohar <zohar@linux.ibm.com>
The kernel has no way of differentiating between a file containing data
or code being opened by an interpreter. The proposed O_MAYEXEC
openat2(2) flag bridges this gap by defining and enabling the
MAY_OPENEXEC flag.
This patch adds IMA policy support for the new MAY_OPENEXEC flag.
Example:
measure func=FILE_CHECK mask=^MAY_OPENEXEC
appraise func=FILE_CHECK appraise_type=imasig mask=^MAY_OPENEXEC
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Lakshmi Ramasubramanian <redacted>
Acked-by: Mickaël Salaün <mic@digikod.net>
(Process nit: if you're sending this on behalf of another author, then
this should be Signed-off-by rather than Acked-by.)
I'm not a co-author of this patch.
from Documentation/process/submitting-patches.rst:
The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OK, I though such tag had to go along with the From/Author, the
Committer or a Co-developed-by tag, but there is also this specific
case. I'll fix that in the next series.
On Thu, Jul 16, 2020 at 04:18:27PM +0200, Mickaël Salaün wrote:
On 15/07/2020 22:06, Kees Cook wrote:
quoted
On Tue, Jul 14, 2020 at 08:16:35PM +0200, Mickaël Salaün wrote:
quoted
The implementation of O_MAYEXEC almost duplicates what execve(2) and
uselib(2) are already doing: setting MAY_OPENEXEC in acc_mode (which can
then be checked as MAY_EXEC, if enforced), and propagating FMODE_EXEC to
_fmode via __FMODE_EXEC flag (which can then trigger a
fanotify/FAN_OPEN_EXEC event).
[...]
Adding __FMODE_EXEC here will immediately change the behaviors of NFS
and fsnotify. If that's going to happen, I think it needs to be under
the control of the later patches doing the behavioral controls.
(specifically, NFS looks like it completely changes its access control
test when this is set and ignores the read/write checks entirely, which
is not what's wanted).
__FMODE_EXEC was suggested by Jan Kara and Matthew Bobrowski because of
fsnotify. However, the NFS handling of SUID binaries [1] indeed leads to
an unintended behavior. This also means that uselib(2) shouldn't work
properly with NFS. I can remove the __FMODE_EXEC flag for now.
I kind of wonder if we need to more completely fix __FMODE_EXEC?
Hmpf, this implies that "fmode" should contain MAY_EXEC? It really looks
like __FMODE_EXEC is a hack for places where only "flags" were passed
around, and this only seems to be an issue for NFS at this point? And it
should be fixable for fsnotify too?
Hmm. (And nothing should use uselib anyway...)
--
Kees Cook
On Thu, Jul 16, 2020 at 04:40:15PM +0200, Mickaël Salaün wrote:
On 15/07/2020 22:40, Kees Cook wrote:
quoted
On Tue, Jul 14, 2020 at 08:16:38PM +0200, Mickaël Salaün wrote:
quoted
From: Mimi Zohar <zohar@linux.ibm.com>
The kernel has no way of differentiating between a file containing data
or code being opened by an interpreter. The proposed O_MAYEXEC
openat2(2) flag bridges this gap by defining and enabling the
MAY_OPENEXEC flag.
This patch adds IMA policy support for the new MAY_OPENEXEC flag.
Example:
measure func=FILE_CHECK mask=^MAY_OPENEXEC
appraise func=FILE_CHECK appraise_type=imasig mask=^MAY_OPENEXEC
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Lakshmi Ramasubramanian <redacted>
Acked-by: Mickaël Salaün <mic@digikod.net>
(Process nit: if you're sending this on behalf of another author, then
this should be Signed-off-by rather than Acked-by.)
I'm not a co-author of this patch.
Correct, but you are part of the delivery path to its entry to the
tree. If you were co-author, you would include "Co-developed-by" with
a Signed-off-by. (So my nit stands)
For excruciating details:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
"The Signed-off-by: tag indicates that the signer was ... in the patch’s
delivery path."
"Co-developed-by: ... is a used to give attribution to co-authors ..."
--
Kees Cook
On Thu, Jul 16, 2020 at 07:59:20AM -0700, Randy Dunlap wrote:
On 7/16/20 7:40 AM, Mickaël Salaün wrote:
quoted
On 15/07/2020 22:40, Kees Cook wrote:
quoted
On Tue, Jul 14, 2020 at 08:16:38PM +0200, Mickaël Salaün wrote:
quoted
From: Mimi Zohar <zohar@linux.ibm.com>
The kernel has no way of differentiating between a file containing data
or code being opened by an interpreter. The proposed O_MAYEXEC
openat2(2) flag bridges this gap by defining and enabling the
MAY_OPENEXEC flag.
This patch adds IMA policy support for the new MAY_OPENEXEC flag.
Example:
measure func=FILE_CHECK mask=^MAY_OPENEXEC
appraise func=FILE_CHECK appraise_type=imasig mask=^MAY_OPENEXEC
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Lakshmi Ramasubramanian <redacted>
Acked-by: Mickaël Salaün <mic@digikod.net>
(Process nit: if you're sending this on behalf of another author, then
this should be Signed-off-by rather than Acked-by.)
I'm not a co-author of this patch.
from Documentation/process/submitting-patches.rst:
The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Thu, Jul 16, 2020 at 04:39:14PM +0200, Mickaël Salaün wrote:
On 15/07/2020 22:37, Kees Cook wrote:
quoted
On Tue, Jul 14, 2020 at 08:16:36PM +0200, Mickaël Salaün wrote:
quoted
@@ -2849,7 +2855,7 @@ static int may_open(const struct path *path, int acc_mode, int flag) case S_IFLNK: return -ELOOP; case S_IFDIR:- if (acc_mode & (MAY_WRITE | MAY_EXEC))+ if (acc_mode & (MAY_WRITE | MAY_EXEC | MAY_OPENEXEC)) return -EISDIR; break;
(I need to figure out where "open for reading" rejects S_IFDIR, since
it's clearly not here...)
Doesn't it come from generic_read_dir() in fs/libfs.c?
quoted
quoted
case S_IFBLK:
@@ -2859,13 +2865,26 @@ static int may_open(const struct path *path, int acc_mode, int flag) fallthrough; case S_IFIFO: case S_IFSOCK:- if (acc_mode & MAY_EXEC)+ if (acc_mode & (MAY_EXEC | MAY_OPENEXEC)) return -EACCES; flag &= ~O_TRUNC; break;
This will immediately break a system that runs code with MAY_OPENEXEC
set but reads from a block, char, fifo, or socket, even in the case of
a sysadmin leaving the "file" sysctl disabled.
As documented, O_MAYEXEC is for regular files. The only legitimate use
case seems to be with pipes, which should probably be allowed when
enforcement is disabled.
By the way Kees, while we fix that for the next series, do you think it
would be relevant, at least for the sake of clarity, to add a
WARN_ON_ONCE(acc_mode & MAY_OPENEXEC) for the S_IFSOCK case, since a
socket cannot be open anyway?
--
Thibaut Sautereau
CLIP OS developer
On Thu, Jul 16, 2020 at 04:39:14PM +0200, Mickaël Salaün wrote:
quoted
On 15/07/2020 22:37, Kees Cook wrote:
quoted
On Tue, Jul 14, 2020 at 08:16:36PM +0200, Mickaël Salaün wrote:
quoted
@@ -2849,7 +2855,7 @@ static int may_open(const struct path *path, int acc_mode, int flag) case S_IFLNK: return -ELOOP; case S_IFDIR:- if (acc_mode & (MAY_WRITE | MAY_EXEC))+ if (acc_mode & (MAY_WRITE | MAY_EXEC | MAY_OPENEXEC)) return -EISDIR; break;
(I need to figure out where "open for reading" rejects S_IFDIR, since
it's clearly not here...)
Doesn't it come from generic_read_dir() in fs/libfs.c?
quoted
quoted
quoted
case S_IFBLK:
@@ -2859,13 +2865,26 @@ static int may_open(const struct path *path, int acc_mode, int flag) fallthrough; case S_IFIFO: case S_IFSOCK:- if (acc_mode & MAY_EXEC)+ if (acc_mode & (MAY_EXEC | MAY_OPENEXEC)) return -EACCES; flag &= ~O_TRUNC; break;
This will immediately break a system that runs code with MAY_OPENEXEC
set but reads from a block, char, fifo, or socket, even in the case of
a sysadmin leaving the "file" sysctl disabled.
As documented, O_MAYEXEC is for regular files. The only legitimate use
case seems to be with pipes, which should probably be allowed when
enforcement is disabled.
By the way Kees, while we fix that for the next series, do you think it
would be relevant, at least for the sake of clarity, to add a
WARN_ON_ONCE(acc_mode & MAY_OPENEXEC) for the S_IFSOCK case, since a
socket cannot be open anyway?
We just did some more tests (for the next patch series) and it turns out
that may_open() can return EACCES before another part returns ENXIO.
As a reminder, the next series will deny access to block devices,
character devices, fifo and socket when opened with O_MAYEXEC *and* if
any policy is enforced (via the sysctl).
The question is then: do we prefer to return EACCES when a policy is
enforced (on a socket), or do we stick to the ENXIO? The EACCES approach
will be more consistent with devices and fifo handling, and seems safer
(belt and suspenders) thought.
On Wed, Jul 22, 2020 at 09:04:28PM +0200, Mickaël Salaün wrote:
On 22/07/2020 18:16, Thibaut Sautereau wrote:
quoted
On Thu, Jul 16, 2020 at 04:39:14PM +0200, Mickaël Salaün wrote:
quoted
On 15/07/2020 22:37, Kees Cook wrote:
quoted
On Tue, Jul 14, 2020 at 08:16:36PM +0200, Mickaël Salaün wrote:
quoted
@@ -2849,7 +2855,7 @@ static int may_open(const struct path *path, int acc_mode, int flag) case S_IFLNK: return -ELOOP; case S_IFDIR:- if (acc_mode & (MAY_WRITE | MAY_EXEC))+ if (acc_mode & (MAY_WRITE | MAY_EXEC | MAY_OPENEXEC)) return -EISDIR; break;
(I need to figure out where "open for reading" rejects S_IFDIR, since
it's clearly not here...)
Doesn't it come from generic_read_dir() in fs/libfs.c?
quoted
quoted
quoted
case S_IFBLK:
@@ -2859,13 +2865,26 @@ static int may_open(const struct path *path, int acc_mode, int flag) fallthrough; case S_IFIFO: case S_IFSOCK:- if (acc_mode & MAY_EXEC)+ if (acc_mode & (MAY_EXEC | MAY_OPENEXEC)) return -EACCES; flag &= ~O_TRUNC; break;
This will immediately break a system that runs code with MAY_OPENEXEC
set but reads from a block, char, fifo, or socket, even in the case of
a sysadmin leaving the "file" sysctl disabled.
As documented, O_MAYEXEC is for regular files. The only legitimate use
case seems to be with pipes, which should probably be allowed when
enforcement is disabled.
By the way Kees, while we fix that for the next series, do you think it
would be relevant, at least for the sake of clarity, to add a
WARN_ON_ONCE(acc_mode & MAY_OPENEXEC) for the S_IFSOCK case, since a
socket cannot be open anyway?
If it's a state that userspace should never be able to reach, then yes,
I think a WARN_ON_ONCE() would be nice.
We just did some more tests (for the next patch series) and it turns out
that may_open() can return EACCES before another part returns ENXIO.
As a reminder, the next series will deny access to block devices,
character devices, fifo and socket when opened with O_MAYEXEC *and* if
any policy is enforced (via the sysctl).
The question is then: do we prefer to return EACCES when a policy is
enforced (on a socket), or do we stick to the ENXIO? The EACCES approach
will be more consistent with devices and fifo handling, and seems safer
(belt and suspenders) thought.
I think EACCES is correct for these cases, since it's a new flag, etc.
--
Kees Cook