From patchwork Tue Jul 14 18:16:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Micka=C3=ABl_Sala=C3=BCn?= X-Patchwork-Id: 11663275 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 853F81392 for ; Tue, 14 Jul 2020 18:17:00 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id C14FC22838 for ; Tue, 14 Jul 2020 18:16:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C14FC22838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-19310-patchwork-kernel-hardening=patchwork.kernel.org@lists.openwall.com Received: (qmail 1573 invoked by uid 550); 14 Jul 2020 18:16:58 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 1553 invoked from network); 14 Jul 2020 18:16:57 -0000 From: =?utf-8?q?Micka=C3=ABl_Sala=C3=BCn?= To: linux-kernel@vger.kernel.org Cc: =?utf-8?q?Micka=C3=ABl_Sala=C3=BCn?= , Aleksa Sarai , Alexei Starovoitov , Al Viro , Andrew Morton , Andy Lutomirski , Christian Brauner , Christian Heimes , Daniel Borkmann , Deven Bowers , Dmitry Vyukov , Eric Biggers , Eric Chiang , Florian Weimer , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Kees Cook , Lakshmi Ramasubramanian , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , =?utf-8?q?Micka=C3=ABl_Sala=C3=BC?= =?utf-8?q?n?= , Mimi Zohar , =?utf-8?q?Philippe_Tr=C3=A9buchet?= , Scott Shell , Sean Christopherson , Shuah Khan , Steve Dower , Steve Grubb , Tetsuo Handa , Thibaut Sautereau , Vincent Strubel , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [PATCH v6 0/7] Add support for O_MAYEXEC Date: Tue, 14 Jul 2020 20:16:31 +0200 Message-Id: <20200714181638.45751-1-mic@digikod.net> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Hi, This sixth patch series mainly adds Kees Cook's file permission check relocations which help to simplify and generalize the previous series. I removed the MAY_EXECMOUNT flag patch which is not useful anymore with this refactoring. I also removed the static enforcement configuration through Kconfig to make this series simpler and because it works in pair with mount configurations (i.e. requires the same capability: CAP_SYS_ADMIN). As requested by Mimi Zohar, I completed the series with one of her patches for IMA. I also picked Kees Cook's patches to consolidate exec permission checking into do_filp_open()'s flow: https://lore.kernel.org/lkml/20200605160013.3954297-1-keescook@chromium.org/ # Goal of O_MAYEXEC The goal of this patch series is to enable to control script execution with interpreters help. A new O_MAYEXEC flag, usable through openat2(2), is added to enable userspace script interpreters to delegate to the kernel (and thus the system security policy) the permission to interpret/execute scripts or other files containing what can be seen as commands. A simple system-wide security policy can be enforced by the system administrator through a sysctl configuration consistent with the mount points or the file access rights. The documentation patch explains the prerequisites. Furthermore, the security policy can also be delegated to an LSM, either a MAC system or an integrity system. For instance, the new kernel MAY_OPENEXEC flag closes a major IMA measurement/appraisal interpreter integrity gap by bringing the ability to check the use of scripts [1]. Other uses are expected, such as for magic-links [2], SGX integration [3], bpffs [4] or IPE [5]. # Prerequisite of its use Userspace needs to adapt to take advantage of this new feature. For example, the PEP 578 [6] (Runtime Audit Hooks) enables Python 3.8 to be extended with policy enforcement points related to code interpretation, which can be used to align with the PowerShell audit features. Additional Python security improvements (e.g. a limited interpreter withou -c, stdin piping of code) are on their way [7]. # Examples The initial idea comes from CLIP OS 4 and the original implementation has been used for more than 12 years: https://github.com/clipos-archive/clipos4_doc Chrome OS has a similar approach: https://chromium.googlesource.com/chromiumos/docs/+/master/security/noexec_shell_scripts.md Userland patches can be found here: https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC Actually, there is more than the O_MAYEXEC changes (which matches this search) e.g., to prevent Python interactive execution. There are patches for Bash, Wine, Java (Icedtea), Busybox's ash, Perl and Python. There are also some related patches which do not directly rely on O_MAYEXEC but which restrict the use of browser plugins and extensions, which may be seen as scripts too: https://github.com/clipos-archive/clipos4_portage-overlay/tree/master/www-client An introduction to O_MAYEXEC was given at the Linux Security Summit Europe 2018 - Linux Kernel Security Contributions by ANSSI: https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s The "write xor execute" principle was explained at Kernel Recipes 2018 - CLIP OS: a defense-in-depth OS: https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s See also an overview article: https://lwn.net/Articles/820000/ This patch series can be applied on top of v5.8-rc5 . This can be tested with CONFIG_SYSCTL. I would really appreciate constructive comments on this patch series. Previous version: https://lore.kernel.org/lkml/20200505153156.925111-1-mic@digikod.net/ [1] https://lore.kernel.org/lkml/1544647356.4028.105.camel@linux.ibm.com/ [2] https://lore.kernel.org/lkml/20190904201933.10736-6-cyphar@cyphar.com/ [3] https://lore.kernel.org/lkml/CALCETrVovr8XNZSroey7pHF46O=kj_c5D9K8h=z2T_cNrpvMig@mail.gmail.com/ [4] https://lore.kernel.org/lkml/CALCETrVeZ0eufFXwfhtaG_j+AdvbzEWE0M3wjXMWVEO7pj+xkw@mail.gmail.com/ [5] https://lore.kernel.org/lkml/20200406221439.1469862-12-deven.desai@linux.microsoft.com/ [6] https://www.python.org/dev/peps/pep-0578/ [7] https://lore.kernel.org/lkml/0c70debd-e79e-d514-06c6-4cd1e021fa8b@python.org/ Regards, Kees Cook (3): exec: Change uselib(2) IS_SREG() failure to EACCES exec: Move S_ISREG() check earlier exec: Move path_noexec() check earlier Mickaël Salaün (3): fs: Introduce O_MAYEXEC flag for openat2(2) fs,doc: Enable to enforce noexec mounts or file exec through O_MAYEXEC selftest/openat2: Add tests for O_MAYEXEC enforcing Mimi Zohar (1): ima: add policy support for the new file open MAY_OPENEXEC flag Documentation/ABI/testing/ima_policy | 2 +- Documentation/admin-guide/sysctl/fs.rst | 45 +++ fs/exec.c | 23 +- fs/fcntl.c | 2 +- fs/namei.c | 31 ++- fs/open.c | 14 +- include/linux/fcntl.h | 2 +- include/linux/fs.h | 3 + include/uapi/asm-generic/fcntl.h | 7 + kernel/sysctl.c | 12 +- security/integrity/ima/ima_main.c | 3 +- security/integrity/ima/ima_policy.c | 15 +- tools/testing/selftests/kselftest_harness.h | 3 + tools/testing/selftests/openat2/Makefile | 3 +- tools/testing/selftests/openat2/config | 1 + tools/testing/selftests/openat2/helpers.h | 1 + .../testing/selftests/openat2/omayexec_test.c | 262 ++++++++++++++++++ 17 files changed, 400 insertions(+), 29 deletions(-) create mode 100644 tools/testing/selftests/openat2/config create mode 100644 tools/testing/selftests/openat2/omayexec_test.c