From: Topi Miettinen <toiwoton@gmail.com> To: "Catalin Marinas" <catalin.marinas@arm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Christoph Hellwig" <hch@infradead.org>, "Lennart Poettering" <lennart@poettering.net>, "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl> Cc: Will Deacon <will@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Eric Biederman <ebiederm@xmission.com>, Kees Cook <keescook@chromium.org>, Szabolcs Nagy <szabolcs.nagy@arm.com>, Mark Brown <broonie@kernel.org>, Jeremy Linton <jeremy.linton@arm.com>, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-abi-devel@lists.sourceforge.net Subject: Re: [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Date: Wed, 13 Apr 2022 21:39:37 +0300 [thread overview] Message-ID: <2a2becf1-fc19-a7da-deb7-1c12781d503d@gmail.com> (raw) In-Reply-To: <20220413134946.2732468-1-catalin.marinas@arm.com> On 13.4.2022 16.49, Catalin Marinas wrote: > Hi, > > The background to this is that systemd has a configuration option called > MemoryDenyWriteExecute [1], implemented as a SECCOMP BPF filter. Its aim > is to prevent a user task from inadvertently creating an executable > mapping that is (or was) writeable. Since such BPF filter is stateless, > it cannot detect mappings that were previously writeable but > subsequently changed to read-only. Therefore the filter simply rejects > any mprotect(PROT_EXEC). The side-effect is that on arm64 with BTI > support (Branch Target Identification), the dynamic loader cannot change > an ELF section from PROT_EXEC to PROT_EXEC|PROT_BTI using mprotect(). > For libraries, it can resort to unmapping and re-mapping but for the > main executable it does not have a file descriptor. The original bug > report in the Red Hat bugzilla - [2] - and subsequent glibc workaround > for libraries - [3]. > > Add in-kernel support for such feature as a DENY_WRITE_EXEC personality > flag, inherited on fork() and execve(). The kernel tracks a previously > writeable mapping via a new VM_WAS_WRITE flag (64-bit only > architectures). I went for a personality flag by analogy with the > READ_IMPLIES_EXEC one. However, I'm happy to change it to a prctl() if > we don't want more personality flags. A minor downside with the > personality flag is that there is no way for the user to query which > flags are supported, so in patch 3 I added an AT_FLAGS bit to advertise > this. With systemd there's a BPF construct to block personality changes (LockPersonality=yes) but I think prctl() would be easier to lock down irrevocably. Requiring or implying NoNewPrivileges could prevent nasty surprises from set-uid Python programs which happen to use FFI. > Posting this as an RFC to start a discussion and cc'ing some of the > systemd guys and those involved in the earlier thread around the glibc > workaround for dynamic libraries [4]. Before thinking of upstreaming > this we'd need the systemd folk to buy into replacing the MDWE SECCOMP > BPF filter with the in-kernel one. As the author of this feature in systemd (also similar feature in Firejail), I'd highly prefer in-kernel version to BPF protection. I'd definitely also want to use this in place of BPF on x86_64 and other arches too. In-kernel version would probably allow covering pretty easily this case (maybe it already does): fd = memfd_create(...); write(fd, malicious_code, sizeof(malicious_code)); mmap(..., PROT_EXEC, ..., fd); Other memory W^X implementations include S.A.R.A [1] and SELinux EXECMEM/EXECSTACK/EXECHEAP protections [2], [3]. SELinux checks IS_PRIVATE(file_inode(file)) and vma->anon_vma != NULL, which might be useful additions here too (or future extensions if you prefer). -Topi [1] https://smeso.it/sara/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c#n3708 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c#n3787
WARNING: multiple messages have this Message-ID (diff)
From: Topi Miettinen <toiwoton@gmail.com> To: "Catalin Marinas" <catalin.marinas@arm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Christoph Hellwig" <hch@infradead.org>, "Lennart Poettering" <lennart@poettering.net>, "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl> Cc: Will Deacon <will@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Eric Biederman <ebiederm@xmission.com>, Kees Cook <keescook@chromium.org>, Szabolcs Nagy <szabolcs.nagy@arm.com>, Mark Brown <broonie@kernel.org>, Jeremy Linton <jeremy.linton@arm.com>, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-abi-devel@lists.sourceforge.net Subject: Re: [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Date: Wed, 13 Apr 2022 21:39:37 +0300 [thread overview] Message-ID: <2a2becf1-fc19-a7da-deb7-1c12781d503d@gmail.com> (raw) In-Reply-To: <20220413134946.2732468-1-catalin.marinas@arm.com> On 13.4.2022 16.49, Catalin Marinas wrote: > Hi, > > The background to this is that systemd has a configuration option called > MemoryDenyWriteExecute [1], implemented as a SECCOMP BPF filter. Its aim > is to prevent a user task from inadvertently creating an executable > mapping that is (or was) writeable. Since such BPF filter is stateless, > it cannot detect mappings that were previously writeable but > subsequently changed to read-only. Therefore the filter simply rejects > any mprotect(PROT_EXEC). The side-effect is that on arm64 with BTI > support (Branch Target Identification), the dynamic loader cannot change > an ELF section from PROT_EXEC to PROT_EXEC|PROT_BTI using mprotect(). > For libraries, it can resort to unmapping and re-mapping but for the > main executable it does not have a file descriptor. The original bug > report in the Red Hat bugzilla - [2] - and subsequent glibc workaround > for libraries - [3]. > > Add in-kernel support for such feature as a DENY_WRITE_EXEC personality > flag, inherited on fork() and execve(). The kernel tracks a previously > writeable mapping via a new VM_WAS_WRITE flag (64-bit only > architectures). I went for a personality flag by analogy with the > READ_IMPLIES_EXEC one. However, I'm happy to change it to a prctl() if > we don't want more personality flags. A minor downside with the > personality flag is that there is no way for the user to query which > flags are supported, so in patch 3 I added an AT_FLAGS bit to advertise > this. With systemd there's a BPF construct to block personality changes (LockPersonality=yes) but I think prctl() would be easier to lock down irrevocably. Requiring or implying NoNewPrivileges could prevent nasty surprises from set-uid Python programs which happen to use FFI. > Posting this as an RFC to start a discussion and cc'ing some of the > systemd guys and those involved in the earlier thread around the glibc > workaround for dynamic libraries [4]. Before thinking of upstreaming > this we'd need the systemd folk to buy into replacing the MDWE SECCOMP > BPF filter with the in-kernel one. As the author of this feature in systemd (also similar feature in Firejail), I'd highly prefer in-kernel version to BPF protection. I'd definitely also want to use this in place of BPF on x86_64 and other arches too. In-kernel version would probably allow covering pretty easily this case (maybe it already does): fd = memfd_create(...); write(fd, malicious_code, sizeof(malicious_code)); mmap(..., PROT_EXEC, ..., fd); Other memory W^X implementations include S.A.R.A [1] and SELinux EXECMEM/EXECSTACK/EXECHEAP protections [2], [3]. SELinux checks IS_PRIVATE(file_inode(file)) and vma->anon_vma != NULL, which might be useful additions here too (or future extensions if you prefer). -Topi [1] https://smeso.it/sara/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c#n3708 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c#n3787 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-13 18:39 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-13 13:49 [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-13 13:49 ` [PATCH RFC 1/4] mm: Track previously writeable vma permission Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-13 13:49 ` [PATCH RFC 2/4] mm, personality: Implement memory-deny-write-execute as a personality flag Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-21 17:37 ` David Hildenbrand 2022-04-21 17:37 ` David Hildenbrand 2022-04-22 10:28 ` Catalin Marinas 2022-04-22 10:28 ` Catalin Marinas 2022-04-22 11:04 ` David Hildenbrand 2022-04-22 11:04 ` David Hildenbrand 2022-04-22 13:12 ` Catalin Marinas 2022-04-22 13:12 ` Catalin Marinas 2022-04-22 17:41 ` David Hildenbrand 2022-04-22 17:41 ` David Hildenbrand 2022-04-13 13:49 ` [PATCH RFC 3/4] fs/binfmt_elf: Tell user-space about the DENY_WRITE_EXEC " Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-13 13:49 ` [PATCH RFC 4/4] arm64: Select ARCH_ENABLE_DENY_WRITE_EXEC Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-13 18:39 ` Topi Miettinen [this message] 2022-04-13 18:39 ` [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Topi Miettinen 2022-04-14 13:49 ` Catalin Marinas 2022-04-14 13:49 ` Catalin Marinas 2022-04-14 18:52 ` Kees Cook 2022-04-14 18:52 ` Kees Cook 2022-04-15 20:01 ` Topi Miettinen 2022-04-15 20:01 ` Topi Miettinen 2022-04-20 13:01 ` Catalin Marinas 2022-04-20 13:01 ` Catalin Marinas 2022-04-20 17:44 ` Kees Cook 2022-04-20 17:44 ` Kees Cook 2022-04-20 19:34 ` Topi Miettinen 2022-04-20 19:34 ` Topi Miettinen 2022-04-20 23:21 ` Kees Cook 2022-04-20 23:21 ` Kees Cook 2022-04-21 15:35 ` Catalin Marinas 2022-04-21 15:35 ` Catalin Marinas 2022-04-21 16:42 ` Kees Cook 2022-04-21 16:42 ` Kees Cook 2022-04-21 17:24 ` Catalin Marinas 2022-04-21 17:24 ` Catalin Marinas 2022-04-21 17:41 ` Kees Cook 2022-04-21 17:41 ` Kees Cook 2022-04-21 18:33 ` Catalin Marinas 2022-04-21 18:33 ` Catalin Marinas 2022-04-21 16:48 ` Topi Miettinen 2022-04-21 16:48 ` Topi Miettinen 2022-04-21 17:28 ` Catalin Marinas 2022-04-21 17:28 ` Catalin Marinas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2a2becf1-fc19-a7da-deb7-1c12781d503d@gmail.com \ --to=toiwoton@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=ebiederm@xmission.com \ --cc=hch@infradead.org \ --cc=jeremy.linton@arm.com \ --cc=keescook@chromium.org \ --cc=lennart@poettering.net \ --cc=linux-abi-devel@lists.sourceforge.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=szabolcs.nagy@arm.com \ --cc=viro@zeniv.linux.org.uk \ --cc=will@kernel.org \ --cc=zbyszek@in.waw.pl \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.