Hi,
This fifth patch series add new kernel configurations (OMAYEXEC_STATIC,
OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to
configure the security policy at kernel build time. As requested by
Mimi Zohar, I completed the series with one of her patches for IMA.
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 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.
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 openat2(2) [2], SGX integration
[3], bpffs [4] or IPE [5].
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.
The initial idea come from CLIP OS 4 and the original implementation has
been used for more than 12 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.7-rc4. This can be tested
with CONFIG_SYSCTL. I would really appreciate constructive comments on
this patch series.
Previous version:
https://lore.kernel.org/lkml/20200428175129.634352-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/
Regards,
Mickaël Salaün (5):
fs: Add support for an O_MAYEXEC flag on openat2(2)
fs: Add a MAY_EXECMOUNT flag to infer the noexec mount property
fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC
selftest/openat2: Add tests for O_MAYEXEC enforcing
doc: Add documentation for the fs.open_mayexec_enforce sysctl
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 | 44 +++
fs/fcntl.c | 2 +-
fs/namei.c | 89 ++++-
fs/open.c | 8 +
include/linux/fcntl.h | 2 +-
include/linux/fs.h | 9 +
include/uapi/asm-generic/fcntl.h | 7 +
kernel/sysctl.c | 9 +
security/Kconfig | 26 ++
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 | 330 ++++++++++++++++++
17 files changed, 544 insertions(+), 10 deletions(-)
create mode 100644 tools/testing/selftests/openat2/config
create mode 100644 tools/testing/selftests/openat2/omayexec_test.c
--
2.26.2
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).
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.
A simple security policy implementation, configured through a dedicated
sysctl, is available in a following patch.
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 11 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
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Thibaut Sautereau <redacted>
Signed-off-by: Vincent Strubel <redacted>
Reviewed-by: Deven Bowers <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <redacted>
---
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).
---
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
On Tue, May 05, 2020 at 05:31:51PM +0200, Mickaël Salaün wrote:
When the O_MAYEXEC flag is passed, openat2(2) may be subject to
additional restrictions depending on a security policy managed by the
kernel through a sysctl or implemented by an LSM thanks to the
inode_permission hook. This new flag is ignored by open(2) and
openat(2).
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.
You touch on this lightly in the cover letter, but it seems there are
plans for Python to restrict stdin parsing? Are there patches pending
anywhere for other interpreters? (e.g. does CLIP OS have such patches?)
There's always a push-back against adding features that have external
dependencies, and then those external dependencies can't happen without
the kernel first adding a feature. :) I like getting these catch-22s
broken, and I think the kernel is the right place to start, especially
since the threat model (and implementation) is already proven out in
CLIP OS, and now with IMA. So, while the interpreter side of this is
still under development, this gives them the tool they need to get it
done on the kernel side. So showing those pieces (as you've done) is
great, and I think finding a little bit more detail here would be even
better.
nit: this needs to be reordered. It's expected that the final SoB
matches the sender. If you're trying to show co-authorship, please
see:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
Based on what I've inferred about author ordering, I think you want:
Co-developed-by: Vincent Strubel <redacted>
Signed-off-by: Vincent Strubel <redacted>
Co-developed-by: Thibaut Sautereau <redacted>
Signed-off-by: Thibaut Sautereau <redacted>
Co-developed-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
From: Christian Heimes <hidden> Date: 2020-05-12 21:40:42
On 12/05/2020 23.05, Kees Cook wrote:
On Tue, May 05, 2020 at 05:31:51PM +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).
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.
You touch on this lightly in the cover letter, but it seems there are
plans for Python to restrict stdin parsing? Are there patches pending
anywhere for other interpreters? (e.g. does CLIP OS have such patches?)
There's always a push-back against adding features that have external
dependencies, and then those external dependencies can't happen without
the kernel first adding a feature. :) I like getting these catch-22s
broken, and I think the kernel is the right place to start, especially
since the threat model (and implementation) is already proven out in
CLIP OS, and now with IMA. So, while the interpreter side of this is
still under development, this gives them the tool they need to get it
done on the kernel side. So showing those pieces (as you've done) is
great, and I think finding a little bit more detail here would be even
better.
Hi,
Python core dev here.
Yes, there are plans to use feature for Python in combination with
additional restrictions. For backwards compatibility reasons we cannot
change the behavior of the default Python interpreter. I have plans to
provide a restricted Python binary that prohibits piping from stdin,
disables -c "some_code()", restricts import locations, and a couple of
other things. O_MAYEXEC flag makes it easier to block imports from
noexec filesystems.
My PoC [1] for a talk [2] last year is inspired by IMA appraisal and a
previous talk by Mickaël on O_MAYEXEC.
Christian
[1] https://github.com/zooba/spython/blob/master/linux_xattr/spython.c
[2]
https://speakerdeck.com/tiran/europython-2019-auditing-hooks-and-security-transparency-for-cpython
On Tue, May 12, 2020 at 11:40:35PM +0200, Christian Heimes wrote:
On 12/05/2020 23.05, Kees Cook wrote:
quoted
On Tue, May 05, 2020 at 05:31:51PM +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).
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.
You touch on this lightly in the cover letter, but it seems there are
plans for Python to restrict stdin parsing? Are there patches pending
anywhere for other interpreters? (e.g. does CLIP OS have such patches?)
There's always a push-back against adding features that have external
dependencies, and then those external dependencies can't happen without
the kernel first adding a feature. :) I like getting these catch-22s
broken, and I think the kernel is the right place to start, especially
since the threat model (and implementation) is already proven out in
CLIP OS, and now with IMA. So, while the interpreter side of this is
still under development, this gives them the tool they need to get it
done on the kernel side. So showing those pieces (as you've done) is
great, and I think finding a little bit more detail here would be even
better.
Hi,
Python core dev here.
Yes, there are plans to use feature for Python in combination with
additional restrictions. For backwards compatibility reasons we cannot
change the behavior of the default Python interpreter. I have plans to
provide a restricted Python binary that prohibits piping from stdin,
disables -c "some_code()", restricts import locations, and a couple of
other things. O_MAYEXEC flag makes it easier to block imports from
noexec filesystems.
My PoC [1] for a talk [2] last year is inspired by IMA appraisal and a
previous talk by Mickaël on O_MAYEXEC.
Christian
[1] https://github.com/zooba/spython/blob/master/linux_xattr/spython.c
[2]
https://speakerdeck.com/tiran/europython-2019-auditing-hooks-and-security-transparency-for-cpython
Ah, fantastic; thank you! Yes, this will go a long way for helping
demonstration to other folks that there are people who will be using
this feature. :)
--
Kees Cook
On Tue, May 05, 2020 at 05:31:51PM +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).
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.
You touch on this lightly in the cover letter, but it seems there are
plans for Python to restrict stdin parsing? Are there patches pending
anywhere for other interpreters? (e.g. does CLIP OS have such patches?)
There's always a push-back against adding features that have external
dependencies, and then those external dependencies can't happen without
the kernel first adding a feature. :) I like getting these catch-22s
broken, and I think the kernel is the right place to start, especially
since the threat model (and implementation) is already proven out in
CLIP OS, and now with IMA. So, while the interpreter side of this is
still under development, this gives them the tool they need to get it
done on the kernel side. So showing those pieces (as you've done) is
great, and I think finding a little bit more detail here would be even
better.
OK, I can add my previous comment in the next cover letter.
nit: this needs to be reordered. It's expected that the final SoB
matches the sender.
OK, I just sorted the list alphabetically.
If you're trying to show co-authorship, please
see:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
Based on what I've inferred about author ordering, I think you want:
Co-developed-by: Vincent Strubel <redacted>
Signed-off-by: Vincent Strubel <redacted>
Co-developed-by: Thibaut Sautereau <redacted>
Signed-off-by: Thibaut Sautereau <redacted>
Co-developed-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
OK, according to the doc I'll remove myself as Co-developped-by because
I'm already in the From, though.
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>
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(-)
@@ -438,7 +438,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);
This new MAY_EXECMOUNT flag enables 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 <redacted>
Reviewed-by: Thibaut Sautereau <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <redacted>
---
fs/namei.c | 2 ++
include/linux/fs.h | 2 ++
2 files changed, 4 insertions(+)
@@ -2849,6 +2849,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)returnerror;
@@ -103,6 +103,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/**flagsinfile.f_mode.NotethatFMODE_READandFMODE_WRITEmustcorrespond
On Tue, May 05, 2020 at 05:31:52PM +0200, Mickaël Salaün wrote:
quoted hunk
This new MAY_EXECMOUNT flag enables 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 <redacted>
Reviewed-by: Thibaut Sautereau <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <redacted>
---
fs/namei.c | 2 ++
include/linux/fs.h | 2 ++
2 files changed, 4 insertions(+)
@@ -2849,6 +2849,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)returnerror;
@@ -103,6 +103,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/**flagsinfile.f_mode.NotethatFMODE_READandFMODE_WRITEmustcorrespond
I find this name unintuitive, but I cannot think of anything better,
since I think my problem is that "MAY" doesn't map to the language I
want to use to describe what this flag is indicating.
Reviewed-by: Kees Cook <redacted>
--
Kees Cook
From: Lev R. Oshvang . <hidden> Date: 2020-05-14 08:14:20
On Wed, May 13, 2020 at 12:09 AM Kees Cook [off-list ref] wrote:
On Tue, May 05, 2020 at 05:31:52PM +0200, Mickaël Salaün wrote:
quoted
This new MAY_EXECMOUNT flag enables 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.
Security policy is expressed by sysadmin by mount -noexec very clear,
I don't think there is a need
in sysctl, wish is system-wide
quoted
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 <redacted>
Reviewed-by: Thibaut Sautereau <redacted>
Cc: Aleksa Sarai <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <redacted>
---
fs/namei.c | 2 ++
include/linux/fs.h | 2 ++
2 files changed, 4 insertions(+)
@@ -2849,6 +2849,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)returnerror;
@@ -103,6 +103,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/**flagsinfile.f_mode.NotethatFMODE_READandFMODE_WRITEmustcorrespond
I find this name unintuitive, but I cannot think of anything better,
since I think my problem is that "MAY" doesn't map to the language I
want to use to describe what this flag is indicating.
Reviewed-by: Kees Cook <redacted>
--
Kees Cook
I think that the original patch was perfect, I quite it again
@@ -3167,6 +3167,14 @@ static int may_open(struct path *path, int
acc_mode, int flag)
+
+ if ((acc_mode & MAY_OPENEXEC)
+ && (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode))
+ && (path->mnt && (path->mnt->mnt_flags & MNT_NOEXEC)))
+ return -EACCES;
+
+
+
error = inode_permission(inode, MAY_OPEN | acc_mode);
As I said in the inline comment above, sysadmin had already express
security policy in a very clear way,
mount -noexec !
I would only check inside inode_permission() whether the file mode is
any ---x permission and deny such
open when file is opened with O_MAYEXEC under MNT_NOEXEC mount point
New sysctl is indeed required to allow userspace that places scripts
or libs under noexec mounts.
fs.mnt_noexec_strict =0 (allow, e) , 1 (deny any file with --x
permission), 2 (deny when O_MAYEXEC absent), for any file with ---x
permissions)
From: Lev R. Oshvang . <hidden> Date: 2020-05-17 16:58:06
On Thu, May 14, 2020 at 6:48 PM Kees Cook [off-list ref] wrote:
On Thu, May 14, 2020 at 11:14:04AM +0300, Lev R. Oshvang . wrote:
quoted
New sysctl is indeed required to allow userspace that places scripts
or libs under noexec mounts.
But since this is a not-uncommon environment, we must have the sysctl
otherwise this change would break those systems.
But I proposed sysctl on a line below.
quoted
fs.mnt_noexec_strict =1 (allow, e) , 1 (deny any file with --x
permission), 2 (deny when O_MAYEXEC absent), for any file with ---x
permissions)
I don't think we want another mount option -- this is already fully
expressed with noexec and the system-wide sysctl.
--
The intended use of proposed sysctl is to ebable sysadmin to decide
whar is desired semantics mount with NO_EXEC option.
fs.mnt_noexec_scope =0 |1|2|3
0 - means old behaviour i.e do nor run executables and scripts (default)
1 - deny any file with --x permissions, i.e executables , script and libs
2 - deny any file when O_MAYEXEC is present.
I think this is enough to handle all use cases and to not break
current sysadmin file mounts setting
I oppose the new O_MAY_EXECMOUNT flag, kernel already has MNT_NO_EXEC,
SB_NOEXEC and SB_I_NOEXEC and I frankly do not understand why so many
variants exist.
Lev
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 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 | 330 ++++++++++++++++++
5 files changed, 337 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/openat2/config
create mode 100644 tools/testing/selftests/openat2/omayexec_test.c
On Tue, May 05, 2020 at 05:31:54PM +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>
Maybe save the system's original sysctl in create_workspace() instead
of always restoring it to 0 in delete_workspace()?
Otherwise, looks good!
--
Kees Cook
On Tue, May 05, 2020 at 05:31:54PM +0200, Mickaël Salaün wrote:
quoted
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>
Enable to forbid access to files open with O_MAYEXEC. 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.
For tailored Linux distributions, it is possible to enforce such
restriction at build time thanks to the CONFIG_OMAYEXEC_STATIC option.
The policy can then be configured with CONFIG_OMAYEXEC_ENFORCE_MOUNT and
CONFIG_OMAYEXEC_ENFORCE_FILE.
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).
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>
---
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()").
---
fs/namei.c | 87 +++++++++++++++++++++++++++++++++++++++++++++-
include/linux/fs.h | 5 +++
kernel/sysctl.c | 9 +++++
security/Kconfig | 26 ++++++++++++++
4 files changed, 126 insertions(+), 1 deletion(-)
@@ -454,6 +535,10 @@ int inode_permission(struct inode *inode, int mask)if(retval)returnretval;+retval=omayexec_inode_permission(inode,mask);+if(retval)+returnretval;+returnsecurity_inode_permission(inode,mask);}EXPORT_SYMBOL(inode_permission);
That help message is a bit confusing IMO. Does setting/enabling OMAYEXEC_STATIC
both enforce O_MAYEXEC at build time and also disable the dedicated sysctl?
Or are these meant to be alternatives, one for what Enabling this kconfig symbol
does and the other for what Disabling this symbol does? If so, it doesn't
say that.
+
+ See Documentation/admin-guide/sysctl/fs.rst for more details.
+
+if OMAYEXEC_STATIC
+
+config OMAYEXEC_ENFORCE_MOUNT
+ bool "Mount restriction"
+ default y
+ ---help---
+ Forbid opening files with the O_MAYEXEC option if their underlying VFS is
+ mounted with the noexec option or if their superblock forbids execution
+ of its content (e.g., /proc).
+
+config OMAYEXEC_ENFORCE_FILE
+ bool "File permission restriction"
+ ---help---
+ Forbid opening files with the O_MAYEXEC option if they are not marked as
+ executable for the current process (e.g., POSIX permissions).
+
+endif # OMAYEXEC_STATIC
+
source "security/selinux/Kconfig"
source "security/smack/Kconfig"
source "security/tomoyo/Kconfig"
That help message is a bit confusing IMO. Does setting/enabling OMAYEXEC_STATIC
both enforce O_MAYEXEC at build time and also disable the dedicated sysctl?
Yes. What about this?
"Define the O_MAYEXEC policy at build time only. As a side effect, this
also disables the fs.open_mayexec_enforce sysctl."
Or are these meant to be alternatives, one for what Enabling this kconfig symbol
does and the other for what Disabling this symbol does? If so, it doesn't
say that.
quoted
+
+ See Documentation/admin-guide/sysctl/fs.rst for more details.
+
+if OMAYEXEC_STATIC
+
+config OMAYEXEC_ENFORCE_MOUNT
+ bool "Mount restriction"
+ default y
+ ---help---
+ Forbid opening files with the O_MAYEXEC option if their underlying VFS is
+ mounted with the noexec option or if their superblock forbids execution
+ of its content (e.g., /proc).
+
+config OMAYEXEC_ENFORCE_FILE
+ bool "File permission restriction"
+ ---help---
+ Forbid opening files with the O_MAYEXEC option if they are not marked as
+ executable for the current process (e.g., POSIX permissions).
+
+endif # OMAYEXEC_STATIC
+
source "security/selinux/Kconfig"
source "security/smack/Kconfig"
source "security/tomoyo/Kconfig"
That help message is a bit confusing IMO. Does setting/enabling OMAYEXEC_STATIC
both enforce O_MAYEXEC at build time and also disable the dedicated sysctl?
Yes. What about this?
"Define the O_MAYEXEC policy at build time only. As a side effect, this
also disables the fs.open_mayexec_enforce sysctl."
Yes, much better. Thanks.
quoted
Or are these meant to be alternatives, one for what Enabling this kconfig symbol
does and the other for what Disabling this symbol does? If so, it doesn't
say that.
quoted
+
+ See Documentation/admin-guide/sysctl/fs.rst for more details.
+
+if OMAYEXEC_STATIC
+
+config OMAYEXEC_ENFORCE_MOUNT
+ bool "Mount restriction"
+ default y
+ ---help---
+ Forbid opening files with the O_MAYEXEC option if their underlying VFS is
+ mounted with the noexec option or if their superblock forbids execution
+ of its content (e.g., /proc).
+
+config OMAYEXEC_ENFORCE_FILE
+ bool "File permission restriction"
+ ---help---
+ Forbid opening files with the O_MAYEXEC option if they are not marked as
+ executable for the current process (e.g., POSIX permissions).
+
+endif # OMAYEXEC_STATIC
+
source "security/selinux/Kconfig"
source "security/smack/Kconfig"
source "security/tomoyo/Kconfig"
On Tue, May 05, 2020 at 05:31:53PM +0200, Mickaël Salaün wrote:
Enable to forbid access to files open with O_MAYEXEC. 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.
Some language tailoring. I might change the first sentence to:
Allow for the enforcement of the O_MAYEXEC openat2(2) flag.
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.
For tailored Linux distributions, it is possible to enforce such
restriction at build time thanks to the CONFIG_OMAYEXEC_STATIC option.
The policy can then be configured with CONFIG_OMAYEXEC_ENFORCE_MOUNT and
CONFIG_OMAYEXEC_ENFORCE_FILE.
OMAYEXEC feels like the wrong name here. Maybe something closer to the
sysctl name? CONFIG_OPEN_MAYEXEC?
And I think it's not needed to have 3 configs for this. That's a lot of
mess for a corner case option. I think I would model this after other
sysctl CONFIGs, and just call this CONFIG_OPEN_MAYEXEC_DEFAULT.
Is _disabling_ the sysctl needed? This patch gets much smaller without
the ..._STATIC bit. (And can we avoid "static", it means different
things to different people. How about invert the logic and call it
CONFIG_OPEN_MAYEXEC_SYSCTL?)
Further notes below...
If you keep CONFIG_OPEN_MAYEXEC_SYSCTL, you could do this in namei.h:
#ifdef CONFIG_OPEN_MAYEXEC_SYSCTL
#define __sysctl_writable __read_mostly
#else
#define __sysctl_write const
#endif
Then with my proposed change to the enforce CONFIG, all of this is
reduced to simply:
int open_mayexec_enforce __sysctl_writable = CONFIG_OPEN_MAYEXEC_DEFAULT;
I don't think any of this is needed. There are no complex bit field
interactions to check for. The sysctl is min=0, max=3. The only thing
special here is checking CAP_MAC_ADMIN. I would just add
proc_dointvec_minmax_macadmin(), like we have for ..._minmax_sysadmin().
+
+/**
+ * omayexec_inode_permission - Check O_MAYEXEC before accessing an inode
+ *
+ * @inode: Inode to check permission on
+ * @mask: Right to check for (%MAY_OPENEXEC, %MAY_EXECMOUNT, %MAY_EXEC)
+ *
+ * Returns 0 if access is permitted, -EACCES otherwise.
+ */
+static inline 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;
+}
More naming nits: I think this should be called may_openexec() to match
the other may_*() functions.
quoted hunk
+
/**
* inode_permission - Check for access rights to a given inode
* @inode: Inode to check permission on
- * @mask: Right to check for (%MAY_READ, %MAY_WRITE, %MAY_EXEC)
+ * @mask: Right to check for (%MAY_READ, %MAY_WRITE, %MAY_EXEC, %MAY_OPENEXEC,
+ * %MAY_EXECMOUNT)
*
* Check for read/write/execute permissions on an inode. We use fs[ug]id for
* this, letting us set arbitrary permissions for filesystem access without
@@ -454,6 +535,10 @@ 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);
On Tue, May 05, 2020 at 05:31:53PM +0200, Mickaël Salaün wrote:
quoted
Enable to forbid access to files open with O_MAYEXEC. 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.
Some language tailoring. I might change the first sentence to:
Allow for the enforcement of the O_MAYEXEC openat2(2) flag.
OK
quoted
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.
For tailored Linux distributions, it is possible to enforce such
restriction at build time thanks to the CONFIG_OMAYEXEC_STATIC option.
The policy can then be configured with CONFIG_OMAYEXEC_ENFORCE_MOUNT and
CONFIG_OMAYEXEC_ENFORCE_FILE.
OMAYEXEC feels like the wrong name here. Maybe something closer to the
sysctl name? CONFIG_OPEN_MAYEXEC?
And I think it's not needed to have 3 configs for this. That's a lot of
mess for a corner case option. I think I would model this after other
sysctl CONFIGs, and just call this CONFIG_OPEN_MAYEXEC_DEFAULT.
OK, I guess you mean to store the default integer value of the sysctl in
this config option.
Is _disabling_ the sysctl needed? This patch gets much smaller without
the ..._STATIC bit. (And can we avoid "static", it means different
things to different people. How about invert the logic and call it
CONFIG_OPEN_MAYEXEC_SYSCTL?)
If you keep CONFIG_OPEN_MAYEXEC_SYSCTL, you could do this in namei.h:
#ifdef CONFIG_OPEN_MAYEXEC_SYSCTL
#define __sysctl_writable __read_mostly
#else
#define __sysctl_write const
#endif
Then with my proposed change to the enforce CONFIG, all of this is
reduced to simply:
int open_mayexec_enforce __sysctl_writable = CONFIG_OPEN_MAYEXEC_DEFAULT;
Except the position of the const, this is clearer indeed.
I don't think any of this is needed. There are no complex bit field
interactions to check for. The sysctl is min=0, max=3. The only thing
special here is checking CAP_MAC_ADMIN. I would just add
proc_dointvec_minmax_macadmin(), like we have for ..._minmax_sysadmin().
OK
quoted
+
+/**
+ * omayexec_inode_permission - Check O_MAYEXEC before accessing an inode
+ *
+ * @inode: Inode to check permission on
+ * @mask: Right to check for (%MAY_OPENEXEC, %MAY_EXECMOUNT, %MAY_EXEC)
+ *
+ * Returns 0 if access is permitted, -EACCES otherwise.
+ */
+static inline 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;
+}
More naming nits: I think this should be called may_openexec() to match
the other may_*() functions.
Other *_inode_permission() functions have a similar meaning and the same
signature. The may_*() functions have various signatures. What do the
filesystem folks prefer?
quoted
+
/**
* inode_permission - Check for access rights to a given inode
* @inode: Inode to check permission on
- * @mask: Right to check for (%MAY_READ, %MAY_WRITE, %MAY_EXEC)
+ * @mask: Right to check for (%MAY_READ, %MAY_WRITE, %MAY_EXEC, %MAY_OPENEXEC,
+ * %MAY_EXECMOUNT)
*
* Check for read/write/execute permissions on an inode. We use fs[ug]id for
* this, letting us set arbitrary permissions for filesystem access without
@@ -454,6 +535,10 @@ 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);
From: Stephen Smalley <stephen.smalley.work@gmail.com> Date: 2020-05-13 15:37:32
On Tue, May 5, 2020 at 11:33 AM Mickaël Salaün [off-list ref] wrote:
Enable to forbid access to files open with O_MAYEXEC. 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.
For tailored Linux distributions, it is possible to enforce such
restriction at build time thanks to the CONFIG_OMAYEXEC_STATIC option.
The policy can then be configured with CONFIG_OMAYEXEC_ENFORCE_MOUNT and
CONFIG_OMAYEXEC_ENFORCE_FILE.
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).
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>
---
@@ -411,10 +412,90 @@ static int sb_permission(struct super_block *sb, struct inode *inode, int mask)
<snip>
+#if defined(CONFIG_SYSCTL) && !defined(CONFIG_OMAYEXEC_STATIC)
+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;
Not fond of using CAP_MAC_ADMIN here (or elsewhere outside of security
modules). The ability to set this sysctl is not equivalent to being
able to load a MAC policy, set arbitrary MAC labels on
processes/files, etc.
+ * omayexec_inode_permission - Check O_MAYEXEC before accessing an inode
+ *
+ * @inode: Inode to check permission on
+ * @mask: Right to check for (%MAY_OPENEXEC, %MAY_EXECMOUNT, %MAY_EXEC)
+ *
+ * Returns 0 if access is permitted, -EACCES otherwise.
+ */
+static inline 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;
+}
I'm wondering if this is being done at the wrong level. I would think
that OMAYEXEC_ENFORCE_FILE would mean to check file execute permission
with respect to all mechanisms/policies, including DAC,
filesystem-specific checking (inode->i_op->permission), security
modules, etc. That requires more than just calling
generic_permission() with MAY_EXEC, which only covers the default
DAC/ACL logic; you'd need to take the handling up a level to
inode_permission() and re-map MAY_OPENEXEC to MAY_EXEC for
do_inode_permission() and security_inode_permission() at least.
Alternatively, we can modify each individual filesystem (that
implements its own i_op->permission) and security module to start
handling MAY_OPENEXEC and have them choose to remap it to a file
execute check (or not) independent of the sysctl. Not sure of your
intent. As it stands, selinux_inode_permission() will ignore the new
MAY_OPENEXEC flag until someone updates it. Likewise for Smack.
AppArmor/TOMOYO would probably need to check and handle FMODE_EXEC in
their file_open hooks since they don't implement inode_permission().
On Wed, May 13, 2020 at 11:37:16AM -0400, Stephen Smalley wrote:
On Tue, May 5, 2020 at 11:33 AM Mickaël Salaün [off-list ref] wrote:
quoted
Enable to forbid access to files open with O_MAYEXEC. 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.
For tailored Linux distributions, it is possible to enforce such
restriction at build time thanks to the CONFIG_OMAYEXEC_STATIC option.
The policy can then be configured with CONFIG_OMAYEXEC_ENFORCE_MOUNT and
CONFIG_OMAYEXEC_ENFORCE_FILE.
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).
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>
---
@@ -411,10 +412,90 @@ static int sb_permission(struct super_block *sb, struct inode *inode, int mask)
<snip>
quoted
+#if defined(CONFIG_SYSCTL) && !defined(CONFIG_OMAYEXEC_STATIC)
+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;
Not fond of using CAP_MAC_ADMIN here (or elsewhere outside of security
modules). The ability to set this sysctl is not equivalent to being
able to load a MAC policy, set arbitrary MAC labels on
processes/files, etc.
That's fair. In that case, perhaps this could just use the existing
_sysadmin helper? (Though I should note that these perm checks actually
need to be in the open, not the read/write ... I thought there was a
series to fix that, but I can't find it now. Regardless, that's
orthogonal to this series.)
quoted
+ * omayexec_inode_permission - Check O_MAYEXEC before accessing an inode
+ *
+ * @inode: Inode to check permission on
+ * @mask: Right to check for (%MAY_OPENEXEC, %MAY_EXECMOUNT, %MAY_EXEC)
+ *
+ * Returns 0 if access is permitted, -EACCES otherwise.
+ */
+static inline 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;
+}
I'm wondering if this is being done at the wrong level. I would think
that OMAYEXEC_ENFORCE_FILE would mean to check file execute permission
with respect to all mechanisms/policies, including DAC,
filesystem-specific checking (inode->i_op->permission), security
modules, etc. That requires more than just calling
generic_permission() with MAY_EXEC, which only covers the default
DAC/ACL logic; you'd need to take the handling up a level to
inode_permission() and re-map MAY_OPENEXEC to MAY_EXEC for
do_inode_permission() and security_inode_permission() at least.
Oh, yeah, that's a good point. Does this need to be a two-pass check, or
can MAY_OPENEXEC get expanded to MAY_EXEC here? Actually, why is this so
deep at all? Shouldn't this be in may_open()?
Like, couldn't just the entire thing just be:
@@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int acc_mode, int flag)break;}+if(unlikely(mask&MAY_OPENEXEC)){+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_MOUNT&&+path_noexec(path))+return-EACCES;+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_FILE)+acc_mode|=MAY_EXEC;+}error=inode_permission(inode,MAY_OPEN|acc_mode);if(error)returnerror;
Alternatively, we can modify each individual filesystem (that
implements its own i_op->permission) and security module to start
handling MAY_OPENEXEC and have them choose to remap it to a file
execute check (or not) independent of the sysctl. Not sure of your
Eek, no, this should be centralized in the VFS, not per-filesystem, but
I do see that it might be possible for a filesystem to actually do the
MAY_OPENEXEC test internally, so the two-pass check wouldn't be needed.
But... I think that can't happen until _everything_ can do the single
pass check, so we always have to make the second call too.
intent. As it stands, selinux_inode_permission() will ignore the new
MAY_OPENEXEC flag until someone updates it. Likewise for Smack.
AppArmor/TOMOYO would probably need to check and handle FMODE_EXEC in
their file_open hooks since they don't implement inode_permission().
Is there any need to teach anything about MAY_OPENEXEC? It'll show up
for the LSMs as (MAY_OPEN | MAY_EXEC).
--
Kees Cook
@@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int acc_mode, int flag)break;}+if(unlikely(mask&MAY_OPENEXEC)){+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_MOUNT&&+path_noexec(path))+return-EACCES;+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_FILE)+acc_mode|=MAY_EXEC;+}error=inode_permission(inode,MAY_OPEN|acc_mode);if(error)returnerror;
FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3
reduced to this plus the Kconfig and sysctl changes, the self tests
pass.
I think this makes things much cleaner and correct.
--
Kees Cook
@@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int acc_mode, int flag)break;}+if(unlikely(mask&MAY_OPENEXEC)){+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_MOUNT&&+path_noexec(path))+return-EACCES;+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_FILE)+acc_mode|=MAY_EXEC;+}error=inode_permission(inode,MAY_OPEN|acc_mode);if(error)returnerror;
FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3
reduced to this plus the Kconfig and sysctl changes, the self tests
pass.
I think this makes things much cleaner and correct.
And a summary of that would be right for the 0/n patch email.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
@@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int acc_mode, int flag)break;}+if(unlikely(mask&MAY_OPENEXEC)){+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_MOUNT&&+path_noexec(path))+return-EACCES;+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_FILE)+acc_mode|=MAY_EXEC;+}error=inode_permission(inode,MAY_OPEN|acc_mode);if(error)returnerror;
FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3
reduced to this plus the Kconfig and sysctl changes, the self tests
pass.
I think this makes things much cleaner and correct.
I think that covers inode-based security modules but not path-based
ones (they don't implement the inode_permission hook). For those, I
would tentatively guess that we need to make sure FMODE_EXEC is set on
the open file and then they need to check for that in their file_open
hooks.
@@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int acc_mode, int flag)break;}+if(unlikely(mask&MAY_OPENEXEC)){+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_MOUNT&&+path_noexec(path))+return-EACCES;+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_FILE)+acc_mode|=MAY_EXEC;+}error=inode_permission(inode,MAY_OPEN|acc_mode);if(error)returnerror;
FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3
reduced to this plus the Kconfig and sysctl changes, the self tests
pass.
I think this makes things much cleaner and correct.
I think that covers inode-based security modules but not path-based
ones (they don't implement the inode_permission hook). For those, I
would tentatively guess that we need to make sure FMODE_EXEC is set on
the open file and then they need to check for that in their file_open
hooks.
Does there need to be an FMODE_OPENEXEC, or is the presence of
FMODE_OPEN with FMODE_EXEC sufficient?
--
Kees Cook
@@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int acc_mode, int flag)break;}+if(unlikely(mask&MAY_OPENEXEC)){+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_MOUNT&&+path_noexec(path))+return-EACCES;+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_FILE)+acc_mode|=MAY_EXEC;+}error=inode_permission(inode,MAY_OPEN|acc_mode);if(error)returnerror;
FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3
reduced to this plus the Kconfig and sysctl changes, the self tests
pass.
I think this makes things much cleaner and correct.
I think that covers inode-based security modules but not path-based
ones (they don't implement the inode_permission hook). For those, I
would tentatively guess that we need to make sure FMODE_EXEC is set on
the open file and then they need to check for that in their file_open
hooks.
Does there need to be an FMODE_OPENEXEC, or is the presence of
FMODE_OPEN with FMODE_EXEC sufficient?
I don't think we need an extra flag/mode bit. But note that 1)
FMODE_OPENED isn't set until after security_file_open() is called so
we can't rely on it there, 2) __FMODE_EXEC aka FMODE_EXEC is set in
f_flags not f_mode, 3) FMODE_EXEC was originally introduced for
distributed filesystems so that they could return ETXTBUSY if the file
was opened for write and execute on different nodes, 4) AppArmor and
TOMOYO have special handling of execve based on current->in_execve so
I guess the only overlap would be for uselib(2).
@@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int acc_mode, int flag)break;}+if(unlikely(mask&MAY_OPENEXEC)){+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_MOUNT&&+path_noexec(path))+return-EACCES;+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_FILE)+acc_mode|=MAY_EXEC;+}error=inode_permission(inode,MAY_OPEN|acc_mode);if(error)returnerror;
FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3
reduced to this plus the Kconfig and sysctl changes, the self tests
pass.
I think this makes things much cleaner and correct.
I think that covers inode-based security modules but not path-based
ones (they don't implement the inode_permission hook). For those, I
would tentatively guess that we need to make sure FMODE_EXEC is set on
the open file and then they need to check for that in their file_open
hooks.
I kept confusing myself about what order things happened in, so I made
these handy notes about the call graph:
openat2(dfd, char * filename, open_how)
do_filp_open(dfd, filename, open_flags)
path_openat(nameidata, open_flags, flags)
do_open(nameidata, file, open_flags)
may_open(path, acc_mode, open_flag)
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)
if (unlikely(f->f_flags & FMODE_EXEC && !S_ISREG(inode->i_mode))) ...
security_file_open(f)
open()
So, it looks like adding FMODE_EXEC into f_flags in do_open() is needed in
addition to injecting MAY_EXEC into acc_mode in do_open()? Hmmm
--
Kees Cook
@@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int acc_mode, int flag)break;}+if(unlikely(mask&MAY_OPENEXEC)){+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_MOUNT&&+path_noexec(path))+return-EACCES;+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_FILE)+acc_mode|=MAY_EXEC;+}error=inode_permission(inode,MAY_OPEN|acc_mode);if(error)returnerror;
FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3
reduced to this plus the Kconfig and sysctl changes, the self tests
pass.
I think this makes things much cleaner and correct.
I think that covers inode-based security modules but not path-based
ones (they don't implement the inode_permission hook). For those, I
would tentatively guess that we need to make sure FMODE_EXEC is set on
the open file and then they need to check for that in their file_open
hooks.
I kept confusing myself about what order things happened in, so I made
these handy notes about the call graph:
openat2(dfd, char * filename, open_how)
do_filp_open(dfd, filename, open_flags)
path_openat(nameidata, open_flags, flags)
do_open(nameidata, file, open_flags)
may_open(path, acc_mode, open_flag)
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)
if (unlikely(f->f_flags & FMODE_EXEC && !S_ISREG(inode->i_mode))) ...
security_file_open(f)
open()
So, it looks like adding FMODE_EXEC into f_flags in do_open() is needed in
addition to injecting MAY_EXEC into acc_mode in do_open()? Hmmm
Just do both in build_open_flags() and be done with it? Looks like he
was already setting FMODE_EXEC in patch 1 so we just need to teach
AppArmor/TOMOYO to check for it and perform file execute checking in
that case if !current->in_execve?
@@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int acc_mode, int flag)break;}+if(unlikely(mask&MAY_OPENEXEC)){+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_MOUNT&&+path_noexec(path))+return-EACCES;+if(sysctl_omayexec_enforce&OMAYEXEC_ENFORCE_FILE)+acc_mode|=MAY_EXEC;+}error=inode_permission(inode,MAY_OPEN|acc_mode);if(error)returnerror;
FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3
reduced to this plus the Kconfig and sysctl changes, the self tests
pass.
I think this makes things much cleaner and correct.
I think that covers inode-based security modules but not path-based
ones (they don't implement the inode_permission hook). For those, I
would tentatively guess that we need to make sure FMODE_EXEC is set on
the open file and then they need to check for that in their file_open
hooks.
I kept confusing myself about what order things happened in, so I made
these handy notes about the call graph:
openat2(dfd, char * filename, open_how)
do_filp_open(dfd, filename, open_flags)
path_openat(nameidata, open_flags, flags)
do_open(nameidata, file, open_flags)
may_open(path, acc_mode, open_flag)
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)
if (unlikely(f->f_flags & FMODE_EXEC && !S_ISREG(inode->i_mode))) ...
security_file_open(f)
open()
So, it looks like adding FMODE_EXEC into f_flags in do_open() is needed in
addition to injecting MAY_EXEC into acc_mode in do_open()? Hmmm
Just do both in build_open_flags() and be done with it? Looks like he
was already setting FMODE_EXEC in patch 1 so we just need to teach
AppArmor/TOMOYO to check for it and perform file execute checking in
that case if !current->in_execve?
I can postpone the file permission check for another series to make this
one simpler (i.e. mount noexec only). Because it depends on the sysctl
setting, it is OK to add this check later, if needed. In the meantime,
AppArmor and Tomoyo could be getting ready for this.
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 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.
Since TOMOYO considers that any file (even standard input which is connected
to keyboard) can provide data which can be interpreted as executable, TOMOYO
does not check traditional "execute permission". TOMOYO's execute permission
serves as a gate for replacing current process with a new file using execve()
syscall. All other calls (e.g. uselib(), open()) are simply treated as
opening a file for read/write/append etc. Therefore,
On 14/05/2020 18:10, Stephen Smalley wrote:> Just do both in build_open_flags() and be done with it? Looks like he
was already setting FMODE_EXEC in patch 1 so we just need to teach> AppArmor/TOMOYO to check for it and perform file execute checking in> that case if !current->in_execve?
regarding TOMOYO, I don't think that TOMOYO needs to perform file execute
checking if !current->in_execve , even if O_MAYEXEC is introduced.
On Thu, May 14, 2020 at 09:16:13PM +0200, Mickaël Salaün wrote:
On 14/05/2020 18:10, Stephen Smalley wrote:
quoted
On Thu, May 14, 2020 at 11:45 AM Kees Cook [off-list ref] wrote:
quoted
So, it looks like adding FMODE_EXEC into f_flags in do_open() is needed in
addition to injecting MAY_EXEC into acc_mode in do_open()? Hmmm
Just do both in build_open_flags() and be done with it? Looks like he
was already setting FMODE_EXEC in patch 1 so we just need to teach
AppArmor/TOMOYO to check for it and perform file execute checking in
that case if !current->in_execve?
I can postpone the file permission check for another series to make this
one simpler (i.e. mount noexec only). Because it depends on the sysctl
setting, it is OK to add this check later, if needed. In the meantime,
AppArmor and Tomoyo could be getting ready for this.
So, after playing around with this series, investigating Stephen's
comments, digging through the existing FMODE_EXEC uses, and spending a
bit more time thinking about Lev and Aleksa's dislike of the sysctls, I've
got a much more radically simplified solution that I think could work.
Maybe I've missed some earlier discussion that ruled this out, but I
couldn't find it: let's just add O_EXEC and be done with it. It actually
makes the execve() path more like openat2() and is much cleaner after
a little refactoring. Here are the results, though I haven't emailed it
yet since I still want to do some more testing:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/o_exec/v1
I look forward to flames! ;)
--
Kees Cook
On Thu, May 14, 2020 at 09:16:13PM +0200, Mickaël Salaün wrote:
quoted
On 14/05/2020 18:10, Stephen Smalley wrote:
quoted
On Thu, May 14, 2020 at 11:45 AM Kees Cook [off-list ref] wrote:
quoted
So, it looks like adding FMODE_EXEC into f_flags in do_open() is needed in
addition to injecting MAY_EXEC into acc_mode in do_open()? Hmmm
Just do both in build_open_flags() and be done with it? Looks like he
was already setting FMODE_EXEC in patch 1 so we just need to teach
AppArmor/TOMOYO to check for it and perform file execute checking in
that case if !current->in_execve?
I can postpone the file permission check for another series to make this
one simpler (i.e. mount noexec only). Because it depends on the sysctl
setting, it is OK to add this check later, if needed. In the meantime,
AppArmor and Tomoyo could be getting ready for this.
So, after playing around with this series, investigating Stephen's
comments, digging through the existing FMODE_EXEC uses, and spending a
bit more time thinking about Lev and Aleksa's dislike of the sysctls, I've
got a much more radically simplified solution that I think could work.
Not having a sysctl would mean that distros will probably have to patch
script interpreters to remove the use of O_MAYEXEC. Or distros would
have to exclude newer version of script interpreters because they
implement O_MAYEXEC. Or distros would have to patch their kernel to
implement themselves the sysctl knob I'm already providing. Sysadmins
may not control the kernel build nor the user space build, they control
the system configuration (some mount point options and some file
execution permissions) but I guess that a distro update breaking a
running system is not acceptable. Either way, unfortunately, I think it
doesn't help anyone to not have a controlling sysctl. The same apply for
access-control LSMs relying on a security policy which can be defined by
sysadmins.
Your commits enforce file exec checks, which is a good thing from a
security point of view, but unfortunately that would requires distros to
update all the packages providing shared objects once the dynamic linker
uses O_MAYEXEC.
Maybe I've missed some earlier discussion that ruled this out, but I
couldn't find it: let's just add O_EXEC and be done with it. It actually
makes the execve() path more like openat2() and is much cleaner after
a little refactoring. Here are the results, though I haven't emailed it
yet since I still want to do some more testing:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/o_exec/v1
I look forward to flames! ;)
Like Florian said, O_EXEC is for execute-only (which obviously doesn't
work for scripts):
https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
On the other hand, the semantic of O_MAYEXEC is complementary to other
O_* flags. It is inspired by the VM_MAYEXEC flag.
The O_EXEC flag is specified for open(2). openat2(2) is Linux-specific
and it is highly unlikely that new flags will be added to open(2) or
openat(2) because of compatibility issues.
FYI, musl implements O_EXEC on Linux with O_PATH:
https://www.openwall.com/lists/musl/2013/02/22/1https://git.musl-libc.org/cgit/musl/commit/?id=6d05d862975188039e648273ceab350d9ab5b69e
However, the O_EXEC flag/semantic could be useful for the dynamic
linkers, i.e. to only be able to map files in an executable (and
read-only) way. If this is OK, then we may want to rename O_MAYEXEC to
something like O_INTERPRET. This way we could have two new flags for
sightly (but important) different use cases. The sysctl bitfield could
be extended to manage both of these flags.
Other than that, the other commits are interesting. I'm a bit worried
about the implication of the f_flags/f_mode change though.
From a practical point of view, I'm also wondering how you intent to
submit this series on LKML without conflicting with the current
O_MAYEXEC series (versions, changes…). I would like you to keep the
warnings from my patches about other ways to execute/interpret code and
the threat model (patch 1/6 and 5/6).
On Fri, May 15, 2020 at 01:04:08PM +0200, Mickaël Salaün wrote:
On 15/05/2020 10:01, Kees Cook wrote:
quoted
On Thu, May 14, 2020 at 09:16:13PM +0200, Mickaël Salaün wrote:
quoted
On 14/05/2020 18:10, Stephen Smalley wrote:
quoted
On Thu, May 14, 2020 at 11:45 AM Kees Cook [off-list ref] wrote:
quoted
So, it looks like adding FMODE_EXEC into f_flags in do_open() is needed in
addition to injecting MAY_EXEC into acc_mode in do_open()? Hmmm
Just do both in build_open_flags() and be done with it? Looks like he
was already setting FMODE_EXEC in patch 1 so we just need to teach
AppArmor/TOMOYO to check for it and perform file execute checking in
that case if !current->in_execve?
I can postpone the file permission check for another series to make this
one simpler (i.e. mount noexec only). Because it depends on the sysctl
setting, it is OK to add this check later, if needed. In the meantime,
AppArmor and Tomoyo could be getting ready for this.
So, after playing around with this series, investigating Stephen's
comments, digging through the existing FMODE_EXEC uses, and spending a
bit more time thinking about Lev and Aleksa's dislike of the sysctls, I've
got a much more radically simplified solution that I think could work.
Not having a sysctl would mean that distros will probably have to patch
script interpreters to remove the use of O_MAYEXEC. Or distros would
have to exclude newer version of script interpreters because they
implement O_MAYEXEC. Or distros would have to patch their kernel to
implement themselves the sysctl knob I'm already providing. Sysadmins
may not control the kernel build nor the user space build, they control
the system configuration (some mount point options and some file
execution permissions) but I guess that a distro update breaking a
running system is not acceptable. Either way, unfortunately, I think it
doesn't help anyone to not have a controlling sysctl. The same apply for
access-control LSMs relying on a security policy which can be defined by
sysadmins.
Your commits enforce file exec checks, which is a good thing from a
security point of view, but unfortunately that would requires distros to
update all the packages providing shared objects once the dynamic linker
uses O_MAYEXEC.
I used to agree with this, but I'm now convinced now that the sysctls are
redundant and will ultimately impede adoption. In looking at what levels
the existing (CLIP OS, Chrome OS) and future (PEP 578) implementations
have needed to do to meaningfully provide the protection, it seems
like software will not be using this flag out of the blue. It'll need
careful addition way beyond the scope of just a sysctl. (As in, I don't
think using O_MAYEXEC is going to just get added without thought to all
interpreters. And developers that DO add it will want to know that the
system will behave in the specified way: having it be off by default
will defeat the purpose of adding the flag for the end users.)
I think it boils down to deciding how to control enforcement: should it
be up to the individual piece of software, or should it be system-wide?
Looking at the patches Chrome OS has made to the shell (and the
accompanying system changes), and Python's overall plans, it seems to
me that the requirements for meaningfully using this flag is going to
be very software-specific.
Now, if the goal is to try to get O_MAYEXEC into every interpreter as
widely as possible without needing to wait for the software-specific
design changes, then I can see the reason to want a default-off global
sysctl. (Though in that case, I suspect it needs to be tied to userns or
something to support containers with different enforcement levels.)
quoted
Maybe I've missed some earlier discussion that ruled this out, but I
couldn't find it: let's just add O_EXEC and be done with it. It actually
makes the execve() path more like openat2() and is much cleaner after
a little refactoring. Here are the results, though I haven't emailed it
yet since I still want to do some more testing:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/o_exec/v1
I look forward to flames! ;)
Like Florian said, O_EXEC is for execute-only (which obviously doesn't
work for scripts):
https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
On the other hand, the semantic of O_MAYEXEC is complementary to other
O_* flags. It is inspired by the VM_MAYEXEC flag.
Ah! I see now -- it's intended to be like the O_*ONLY flags. I
misunderstood what Florian meant. Okay, sure that's a good enough reason
for me to retain the O_MAYEXEC name. (And then I think this distinction
from O_EXEC needs to be well documented.)
The O_EXEC flag is specified for open(2). openat2(2) is Linux-specific
and it is highly unlikely that new flags will be added to open(2) or
openat(2) because of compatibility issues.
Agreed. (Which in my mind is further rationale that a sysctl isn't
wanted here: adding O_MAYEXEC will need to be very intentional.)
FYI, musl implements O_EXEC on Linux with O_PATH:
https://www.openwall.com/lists/musl/2013/02/22/1https://git.musl-libc.org/cgit/musl/commit/?id=6d05d862975188039e648273ceab350d9ab5b69e
However, the O_EXEC flag/semantic could be useful for the dynamic
linkers, i.e. to only be able to map files in an executable (and
read-only) way. If this is OK, then we may want to rename O_MAYEXEC to
something like O_INTERPRET. This way we could have two new flags for
sightly (but important) different use cases. The sysctl bitfield could
be extended to manage both of these flags.
If it's not O_EXEC, then I do like keeping "EXEC" in the flag name,
since it has direct relation to noexec and exec-bit. I'm fine with
O_MAYEXEC -- I just couldn't find the rationale for why it _shouldn't_
be O_EXEC. (Which is now well understood -- thanks to you you and
Florian!)
Other than that, the other commits are interesting. I'm a bit worried
about the implication of the f_flags/f_mode change though.
That's an area I also didn't see why FMODE_EXEC wasn't retained in
f_mode. Especially given the nature of the filtering out FMODE_NONOTIFY
in build_open_flags(). Why would FMODE_NONOTIFY move to f_mode, but not
FMODE_EXEC?
From a practical point of view, I'm also wondering how you intent to
submit this series on LKML without conflicting with the current
O_MAYEXEC series (versions, changes…). I would like you to keep the
warnings from my patches about other ways to execute/interpret code and
the threat model (patch 1/6 and 5/6).
I don't intend it to conflict -- I wanted to have actual code written
out to share as a basis for discussion. I didn't want to talk about
"maybe we can try $foo", but rather "here's $foo; what do y'all think?"
:)
--
Kees Cook
On Fri, May 15, 2020 at 01:04:08PM +0200, Mickaël Salaün wrote:
quoted
On 15/05/2020 10:01, Kees Cook wrote:
quoted
On Thu, May 14, 2020 at 09:16:13PM +0200, Mickaël Salaün wrote:
quoted
On 14/05/2020 18:10, Stephen Smalley wrote:
quoted
On Thu, May 14, 2020 at 11:45 AM Kees Cook [off-list ref] wrote:
quoted
So, it looks like adding FMODE_EXEC into f_flags in do_open() is needed in
addition to injecting MAY_EXEC into acc_mode in do_open()? Hmmm
Just do both in build_open_flags() and be done with it? Looks like he
was already setting FMODE_EXEC in patch 1 so we just need to teach
AppArmor/TOMOYO to check for it and perform file execute checking in
that case if !current->in_execve?
I can postpone the file permission check for another series to make this
one simpler (i.e. mount noexec only). Because it depends on the sysctl
setting, it is OK to add this check later, if needed. In the meantime,
AppArmor and Tomoyo could be getting ready for this.
So, after playing around with this series, investigating Stephen's
comments, digging through the existing FMODE_EXEC uses, and spending a
bit more time thinking about Lev and Aleksa's dislike of the sysctls, I've
got a much more radically simplified solution that I think could work.
Not having a sysctl would mean that distros will probably have to patch
script interpreters to remove the use of O_MAYEXEC. Or distros would
have to exclude newer version of script interpreters because they
implement O_MAYEXEC. Or distros would have to patch their kernel to
implement themselves the sysctl knob I'm already providing. Sysadmins
may not control the kernel build nor the user space build, they control
the system configuration (some mount point options and some file
execution permissions) but I guess that a distro update breaking a
running system is not acceptable. Either way, unfortunately, I think it
doesn't help anyone to not have a controlling sysctl. The same apply for
access-control LSMs relying on a security policy which can be defined by
sysadmins.
Your commits enforce file exec checks, which is a good thing from a
security point of view, but unfortunately that would requires distros to
update all the packages providing shared objects once the dynamic linker
uses O_MAYEXEC.
I used to agree with this, but I'm now convinced now that the sysctls are
redundant and will ultimately impede adoption. In looking at what levels
the existing (CLIP OS, Chrome OS) and future (PEP 578) implementations
have needed to do to meaningfully provide the protection, it seems
like software will not be using this flag out of the blue. It'll need
careful addition way beyond the scope of just a sysctl. (As in, I don't
think using O_MAYEXEC is going to just get added without thought to all
interpreters. And developers that DO add it will want to know that the
system will behave in the specified way: having it be off by default
will defeat the purpose of adding the flag for the end users.)
I think that the different points of view should be the following:
- kernel developer: the app *may* behave this way;
- user space developer: the app *should* behave this way;
- sysadmin: the app *must* behave this way (either enforcing O_MAYEXEC
or not).
The idea is to push adoption of O_MAYEXEC to upstream interpreters,
knowing that it will not break anything on running systems which do not
care about this features. However, on systems which want this feature
enforced, there will be knowledgeable peoples (i.e. sysadmins who
enforced O_MAYEXEC deliberately) to manage it.
If we don't give the opportunity to sysadmins to control this feature,
no upstream interpreters will adopt it. Only tailored distro will use
it, maybe with custom LSM or other way to enforce it anyway, and having
a sysctl or not is not an issue neither. I think it would be a missed
opportunity to help harden most Linux systems.
I think it boils down to deciding how to control enforcement: should it
be up to the individual piece of software, or should it be system-wide?
Looking at the patches Chrome OS has made to the shell (and the
accompanying system changes), and Python's overall plans, it seems to
me that the requirements for meaningfully using this flag is going to
be very software-specific.
Now, if the goal is to try to get O_MAYEXEC into every interpreter as
widely as possible without needing to wait for the software-specific
design changes, then I can see the reason to want a default-off global
sysctl.
Yes, that is our intention: to make this flag used by most interpreters,
without breaking any existing systems.
(Though in that case, I suspect it needs to be tied to userns or
something to support containers with different enforcement levels.)
The LSMs already manage security policies, but the sysctl could indeed
be tied to mount namespaces. This is interesting, but it requires more
complexity. We can start by the current sysctl's bits to manage all the
mount namespaces.
quoted
quoted
Maybe I've missed some earlier discussion that ruled this out, but I
couldn't find it: let's just add O_EXEC and be done with it. It actually
makes the execve() path more like openat2() and is much cleaner after
a little refactoring. Here are the results, though I haven't emailed it
yet since I still want to do some more testing:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/o_exec/v1
I look forward to flames! ;)
Like Florian said, O_EXEC is for execute-only (which obviously doesn't
work for scripts):
https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
On the other hand, the semantic of O_MAYEXEC is complementary to other
O_* flags. It is inspired by the VM_MAYEXEC flag.
Ah! I see now -- it's intended to be like the O_*ONLY flags. I
misunderstood what Florian meant. Okay, sure that's a good enough reason
for me to retain the O_MAYEXEC name. (And then I think this distinction
from O_EXEC needs to be well documented.)
quoted
The O_EXEC flag is specified for open(2). openat2(2) is Linux-specific
and it is highly unlikely that new flags will be added to open(2) or
openat(2) because of compatibility issues.
Agreed. (Which in my mind is further rationale that a sysctl isn't
wanted here: adding O_MAYEXEC will need to be very intentional.)
quoted
FYI, musl implements O_EXEC on Linux with O_PATH:
https://www.openwall.com/lists/musl/2013/02/22/1https://git.musl-libc.org/cgit/musl/commit/?id=6d05d862975188039e648273ceab350d9ab5b69e
However, the O_EXEC flag/semantic could be useful for the dynamic
linkers, i.e. to only be able to map files in an executable (and
read-only) way. If this is OK, then we may want to rename O_MAYEXEC to
something like O_INTERPRET. This way we could have two new flags for
sightly (but important) different use cases. The sysctl bitfield could
be extended to manage both of these flags.
If it's not O_EXEC, then I do like keeping "EXEC" in the flag name,
since it has direct relation to noexec and exec-bit. I'm fine with
O_MAYEXEC -- I just couldn't find the rationale for why it _shouldn't_
be O_EXEC. (Which is now well understood -- thanks to you you and
Florian!)
quoted
Other than that, the other commits are interesting. I'm a bit worried
about the implication of the f_flags/f_mode change though.
That's an area I also didn't see why FMODE_EXEC wasn't retained in
f_mode. Especially given the nature of the filtering out FMODE_NONOTIFY
in build_open_flags(). Why would FMODE_NONOTIFY move to f_mode, but not
FMODE_EXEC?
quoted
From a practical point of view, I'm also wondering how you intent to
submit this series on LKML without conflicting with the current
O_MAYEXEC series (versions, changes…). I would like you to keep the
warnings from my patches about other ways to execute/interpret code and
the threat model (patch 1/6 and 5/6).
I don't intend it to conflict -- I wanted to have actual code written
out to share as a basis for discussion. I didn't want to talk about
"maybe we can try $foo", but rather "here's $foo; what do y'all think?"
:)
On Wed, May 13, 2020 at 11:37:16AM -0400, Stephen Smalley wrote:
quoted
On Tue, May 5, 2020 at 11:33 AM Mickaël Salaün [off-list ref] wrote:
quoted
Enable to forbid access to files open with O_MAYEXEC. 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.
For tailored Linux distributions, it is possible to enforce such
restriction at build time thanks to the CONFIG_OMAYEXEC_STATIC option.
The policy can then be configured with CONFIG_OMAYEXEC_ENFORCE_MOUNT and
CONFIG_OMAYEXEC_ENFORCE_FILE.
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).
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>
---
@@ -411,10 +412,90 @@ static int sb_permission(struct super_block *sb, struct inode *inode, int mask)
<snip>
quoted
+#if defined(CONFIG_SYSCTL) && !defined(CONFIG_OMAYEXEC_STATIC)
+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;
Not fond of using CAP_MAC_ADMIN here (or elsewhere outside of security
modules). The ability to set this sysctl is not equivalent to being
able to load a MAC policy, set arbitrary MAC labels on
processes/files, etc.
That's fair. In that case, perhaps this could just use the existing
_sysadmin helper? (Though I should note that these perm checks actually
need to be in the open, not the read/write ... I thought there was a
series to fix that, but I can't find it now. Regardless, that's
orthogonal to this series.)
OK, I'll switch to CAP_SYS_ADMIN with proc_dointvec_minmax_sysadmin().
This sysctl enables to propagate executable permission to userspace
thanks to the O_MAYEXEC flag.
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 v3:
* Switch back to O_MAYEXEC and highlight that it is only taken into
account by openat2(2).
Changes since v2:
* Update documentation with the new RESOLVE_MAYEXEC.
* Improve explanations, including concerns about LD_PRELOAD.
Changes since v1:
* Move from LSM/Yama to sysctl/fs .
---
Documentation/admin-guide/sysctl/fs.rst | 44 +++++++++++++++++++++++++
1 file changed, 44 insertions(+)
@@ -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,49 @@ 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_MAC_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 at+https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC .++ overflowgid & overflowuid -------------------------
Hi,
This fifth patch series add new kernel configurations (OMAYEXEC_STATIC,
OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to
configure the security policy at kernel build time. As requested by
Mimi Zohar, I completed the series with one of her patches for IMA.
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 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.
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 openat2(2) [2], SGX integration
[3], bpffs [4] or IPE [5].
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.
The initial idea come from CLIP OS 4 and the original implementation has
been used for more than 12 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.7-rc4. This can be tested
with CONFIG_SYSCTL. I would really appreciate constructive comments on
this patch series.
Previous version:
https://lore.kernel.org/lkml/20200428175129.634352-1-mic@digikod.net/
From: Lev R. Oshvang . <hidden> Date: 2020-05-06 13:58:32
On Tue, May 5, 2020 at 6:36 PM Mickaël Salaün [off-list ref] wrote:
On 05/05/2020 17:31, Mickaël Salaün wrote:
quoted
Hi,
This fifth patch series add new kernel configurations (OMAYEXEC_STATIC,
OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to
configure the security policy at kernel build time. As requested by
Mimi Zohar, I completed the series with one of her patches for IMA.
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 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.
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 openat2(2) [2], SGX integration
[3], bpffs [4] or IPE [5].
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.
The initial idea come from CLIP OS 4 and the original implementation has
been used for more than 12 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.7-rc4. This can be tested
with CONFIG_SYSCTL. I would really appreciate constructive comments on
this patch series.
Previous version:
https://lore.kernel.org/lkml/20200428175129.634352-1-mic@digikod.net/
Hi Michael
I have couple of question
1. Why you did not add O_MAYEXEC to open()?
Some time ago (around v4.14) open() did not return EINVAL when
VALID_OPEN_FLAGS check failed.
Now it does, so I do not see a problem that interpreter will use
simple open(), ( Although that path might be manipulated, but file
contents will be verified by IMA)
2. When you apply a new flag to mount, it means that IMA will check
all files under this mount and it does not matter whether the file in
question is a script or not.
IMHO it is too hard overhead for performance reasons.
Regards,
LEv
On 2020-05-06, Lev R. Oshvang . [off-list ref] wrote:
On Tue, May 5, 2020 at 6:36 PM Mickaël Salaün [off-list ref] wrote:
quoted
On 05/05/2020 17:31, Mickaël Salaün wrote:
quoted
Hi,
This fifth patch series add new kernel configurations (OMAYEXEC_STATIC,
OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to
configure the security policy at kernel build time. As requested by
Mimi Zohar, I completed the series with one of her patches for IMA.
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 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.
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 openat2(2) [2], SGX integration
[3], bpffs [4] or IPE [5].
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.
The initial idea come from CLIP OS 4 and the original implementation has
been used for more than 12 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.7-rc4. This can be tested
with CONFIG_SYSCTL. I would really appreciate constructive comments on
this patch series.
Previous version:
https://lore.kernel.org/lkml/20200428175129.634352-1-mic@digikod.net/
Hi Michael
I have couple of question
1. Why you did not add O_MAYEXEC to open()?
Some time ago (around v4.14) open() did not return EINVAL when
VALID_OPEN_FLAGS check failed.
Now it does, so I do not see a problem that interpreter will use
simple open(), ( Although that path might be manipulated, but file
contents will be verified by IMA)
You don't get -EINVAL from open() in the case of unknown flags, that's
something only openat2() does in the open*() family. Hence why it's only
introduced for openat2().
2. When you apply a new flag to mount, it means that IMA will check
all files under this mount and it does not matter whether the file in
question is a script or not.
IMHO it is too hard overhead for performance reasons.
Regards,
LEv
On Tue, May 5, 2020 at 6:36 PM Mickaël Salaün [off-list ref] wrote:
quoted
On 05/05/2020 17:31, Mickaël Salaün wrote:
quoted
Hi,
This fifth patch series add new kernel configurations (OMAYEXEC_STATIC,
OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to
configure the security policy at kernel build time. As requested by
Mimi Zohar, I completed the series with one of her patches for IMA.
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 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.
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 openat2(2) [2], SGX integration
[3], bpffs [4] or IPE [5].
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.
The initial idea come from CLIP OS 4 and the original implementation has
been used for more than 12 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.7-rc4. This can be tested
with CONFIG_SYSCTL. I would really appreciate constructive comments on
this patch series.
Previous version:
https://lore.kernel.org/lkml/20200428175129.634352-1-mic@digikod.net/
Hi Michael
I have couple of question
1. Why you did not add O_MAYEXEC to open()?
Some time ago (around v4.14) open() did not return EINVAL when
VALID_OPEN_FLAGS check failed.
Now it does, so I do not see a problem that interpreter will use
simple open(), ( Although that path might be manipulated, but file
contents will be verified by IMA)
Aleksa replied to this.
2. When you apply a new flag to mount, it means that IMA will check
all files under this mount and it does not matter whether the file in
question is a script or not.
IMHO it is too hard overhead for performance reasons.
This patch series doesn't change the way IMA handles mount points.
From: David Laight <hidden> Date: 2020-05-07 08:05:10
From: Mickaël Salaün
Sent: 05 May 2020 16:32
This fifth patch series add new kernel configurations (OMAYEXEC_STATIC,
OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to
configure the security policy at kernel build time. As requested by
Mimi Zohar, I completed the series with one of her patches for IMA.
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 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.
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 openat2(2) [2], SGX integration
[3], bpffs [4] or IPE [5].
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.
The initial idea come from CLIP OS 4 and the original implementation has
been used for more than 12 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.7-rc4. This can be tested
with CONFIG_SYSCTL. I would really appreciate constructive comments on
this patch series.
None of that description actually says what the patch actually does.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Sent: 05 May 2020 16:32
This fifth patch series add new kernel configurations (OMAYEXEC_STATIC,
OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to
configure the security policy at kernel build time. As requested by
Mimi Zohar, I completed the series with one of her patches for IMA.
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 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.
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 openat2(2) [2], SGX integration
[3], bpffs [4] or IPE [5].
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.
The initial idea come from CLIP OS 4 and the original implementation has
been used for more than 12 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.7-rc4. This can be tested
with CONFIG_SYSCTL. I would really appreciate constructive comments on
this patch series.
None of that description actually says what the patch actually does.
"Add support for O_MAYEXEC" "to enable to control script execution".
What is not clear here? This seems well understood by other commenters.
The documentation patch and the talks can also help.
From: David Laight <hidden> Date: 2020-05-07 09:00:26
From: Mickaël Salaün
Sent: 07 May 2020 09:37
...
quoted
None of that description actually says what the patch actually does.
"Add support for O_MAYEXEC" "to enable to control script execution".
What is not clear here? This seems well understood by other commenters.
The documentation patch and the talks can also help.
I'm guessing that passing O_MAYEXEC to open() requests the kernel
check for execute 'x' permissions (as well as read).
Then kernel policy determines whether 'read' access is actually enough,
or whether 'x' access (possibly masked by mount permissions) is needed.
If that is true, two lines say what is does.
Have you ever set a shell script permissions to --x--s--x ?
Ends up being executable by everyone except the owner!
Having the kernel pass all '#!' files to their interpreters
through an open fd might help security.
In that case the user doesn't need read access to the file
in order to get an interpreter to process it.
(You'd need to stop strace showing the contents to actually
hide them.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
None of that description actually says what the patch actually does.
"Add support for O_MAYEXEC" "to enable to control script execution".
What is not clear here? This seems well understood by other commenters.
The documentation patch and the talks can also help.
I'm guessing that passing O_MAYEXEC to open() requests the kernel
check for execute 'x' permissions (as well as read).
Yes, but only with openat2().
Then kernel policy determines whether 'read' access is actually enough,
or whether 'x' access (possibly masked by mount permissions) is needed.
If that is true, two lines say what is does.
The "A simple system-wide security policy" paragraph introduce that, but
I'll highlight it in the next cover letter. The most important point is
to understand why it is required, before getting to how it will be
implemented.
Have you ever set a shell script permissions to --x--s--x ?
Ends up being executable by everyone except the owner!
In this case the script is indeed executable but it can't be executed
because the interpreter (i.e. the user) needs to be able to read the
file. Of course, if the user has CAP_DAC_OVERRIDE (like the root user),
read is still allowed.
Having the kernel pass all '#!' files to their interpreters
through an open fd might help security.
This is interesting but it doesn't address the current issue: being able
to have a consistent (script) executability system policy. Maybe its
this point of view which wasn't clear enough?
In that case the user doesn't need read access to the file
in order to get an interpreter to process it.
Yes, but this brings security issues, because the interpreter (i.e. the
user) would then be able to read files without read permission.
(You'd need to stop strace showing the contents to actually
hide them.)
It doesn't matter if the process is traced or not, the kernel handles
impersonation scopes thanks to ptrace_may_access().
From: David Laight <hidden> Date: 2020-05-07 09:44:26
From: Mickaël Salaün <mic@digikod.net>
Sent: 07 May 2020 10:30
On 07/05/2020 11:00, David Laight wrote:
quoted
From: Mickaël Salaün
quoted
Sent: 07 May 2020 09:37
...
quoted
quoted
None of that description actually says what the patch actually does.
"Add support for O_MAYEXEC" "to enable to control script execution".
What is not clear here? This seems well understood by other commenters.
The documentation patch and the talks can also help.
I'm guessing that passing O_MAYEXEC to open() requests the kernel
check for execute 'x' permissions (as well as read).
Yes, but only with openat2().
It can't matter if the flag is ignored.
It just means the kernel isn't enforcing the policy.
If openat2() fail because the flag is unsupported then
the application will need to retry without the flag.
So if the user has any ability create executable files this
is all pointless (from a security point of view).
The user can either copy the file or copy in an interpreter
that doesn't request O_MAYEXEC.
It might stop accidental issues, but nothing malicious.
quoted
Then kernel policy determines whether 'read' access is actually enough,
or whether 'x' access (possibly masked by mount permissions) is needed.
If that is true, two lines say what is does.
The "A simple system-wide security policy" paragraph introduce that, but
I'll highlight it in the next cover letter.
No it doesn't.
It just says there is some kind of policy that some flags change.
It doesn't say what is being checked for.
The most important point is
to understand why it is required, before getting to how it will be
implemented.
But you don't say what is required.
Just a load of buzzword ramblings.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Sent: 07 May 2020 10:30
On 07/05/2020 11:00, David Laight wrote:
quoted
From: Mickaël Salaün
quoted
Sent: 07 May 2020 09:37
...
quoted
quoted
None of that description actually says what the patch actually does.
"Add support for O_MAYEXEC" "to enable to control script execution".
What is not clear here? This seems well understood by other commenters.
The documentation patch and the talks can also help.
I'm guessing that passing O_MAYEXEC to open() requests the kernel
check for execute 'x' permissions (as well as read).
Yes, but only with openat2().
It can't matter if the flag is ignored.
It just means the kernel isn't enforcing the policy.
If openat2() fail because the flag is unsupported then
the application will need to retry without the flag.
I don't get what you want to prove. Please read carefully the cover
letter, the use case and the threat model.
So if the user has any ability create executable files this
is all pointless (from a security point of view).
The user can either copy the file or copy in an interpreter
that doesn't request O_MAYEXEC.>
It might stop accidental issues, but nothing malicious.
The execute permission (like the write permission) does not only depends
on the permission set on files, but it also depends on the
options/permission of their mount points, the MAC policy, etc. The
initial use case to enforce O_MAYEXEC is to rely on the noexec mount option.
If you want a consistent policy, you need to make one. Only dealing with
file properties may not be enough. This is explain in the cover letter
and the patches. If you allow all users to write and execute their
files, then there is no point in enforcing anything with O_MAYEXEC.
quoted
quoted
Then kernel policy determines whether 'read' access is actually enough,
or whether 'x' access (possibly masked by mount permissions) is needed.
If that is true, two lines say what is does.
The "A simple system-wide security policy" paragraph introduce that, but
I'll highlight it in the next cover letter.
No it doesn't.
It just says there is some kind of policy that some flags change.
It doesn't say what is being checked for.
It said "the mount points or the file access rights". Please take a look
at the documentation patch.
quoted
The most important point is
to understand why it is required, before getting to how it will be
implemented.
But you don't say what is required.
A consistent policy. Please take a look at the documentation patch which
explains the remaining prerequisites. You can also take a look at the
talks for further details.
Just a load of buzzword ramblings.
It is a summary. Can you please suggest something better?