From: Topi Miettinen <toiwoton@gmail.com>
To: Salvatore Mesoraca <s.mesoraca16@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
systemd-devel@lists.freedesktop.org,
Kees Cook <keescook@chromium.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jeremy Linton <jeremy.linton@arm.com>,
Mark Brown <broonie@kernel.org>,
linux-hardening@vger.kernel.org, libc-alpha@sourceware.org,
Dave Martin <dave.martin@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
Date: Sat, 24 Oct 2020 14:34:06 +0300 [thread overview]
Message-ID: <3cb894d4-049f-aa25-4450-d1df36a1b92e@gmail.com> (raw)
In-Reply-To: <CAJHCu1Jrtx=OVEiTVwPJg7CxRkV83tS=HsYeLoAGRf_tgYq_iQ@mail.gmail.com>
On 23.10.2020 20.52, Salvatore Mesoraca wrote:
> Hi,
>
> On Thu, 22 Oct 2020 at 23:24, Topi Miettinen <toiwoton@gmail.com> wrote:
>> SARA looks interesting. What is missing is a prctl() to enable all W^X
>> protections irrevocably for the current process, then systemd could
>> enable it for services with MemoryDenyWriteExecute=yes.
>
> SARA actually has a procattr[0] interface to do just that.
> There is also a library[1] to help using it.
That means that /proc has to be available and writable at that point, so
setting up procattrs has to be done before mount namespaces are set up.
In general, it would be nice for sandboxing facilities in kernel if
there would be a way to start enforcing restrictions only at next
execve(), like setexeccon() for SELinux and aa_change_onexec() for
AppArmor. Otherwise the exact order of setting up various sandboxing
options can be very tricky to arrange correctly, since each option may
have a subtle effect to the sandboxing features enabled later. In case
of SARA, the operations done between shuffling the mount namespace and
before execve() shouldn't be affected so it isn't important. Even if it
did (a new sandboxing feature in the future would need trampolines or
JIT code generation), maybe the procattr file could be opened early but
it could be written closer to execve().
-Topi
_______________________________________________
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:[~2020-10-24 11:35 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com>
2020-10-22 7:18 ` [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Lennart Poettering
2020-10-22 7:54 ` Florian Weimer
2020-10-22 8:17 ` Topi Miettinen
2020-10-22 8:25 ` Florian Weimer
2020-10-22 8:29 ` Szabolcs Nagy
2020-10-22 8:38 ` Lennart Poettering
2020-10-22 9:31 ` Catalin Marinas
2020-10-22 10:12 ` Topi Miettinen
2020-10-22 10:27 ` Florian Weimer
2020-10-23 6:13 ` Szabolcs Nagy
2020-10-23 9:04 ` Catalin Marinas
2020-10-22 10:03 ` Topi Miettinen
2020-10-22 8:05 ` Szabolcs Nagy
2020-10-22 8:31 ` Lennart Poettering
[not found] ` <20201022075447.GO3819@arm.com>
2020-10-22 10:39 ` Topi Miettinen
2020-10-22 20:02 ` Kees Cook
2020-10-22 22:24 ` Topi Miettinen
2020-10-23 17:52 ` Salvatore Mesoraca
2020-10-24 11:34 ` Topi Miettinen [this message]
2020-10-24 14:12 ` Salvatore Mesoraca
2020-10-25 13:42 ` Jordan Glover
2020-10-23 9:02 ` Catalin Marinas
2020-10-24 11:01 ` Topi Miettinen
2020-10-26 14:52 ` Catalin Marinas
2020-10-26 15:56 ` Dave Martin
2020-10-26 16:51 ` Mark Brown
2020-10-26 16:31 ` Topi Miettinen
2020-10-26 16:24 ` Dave Martin
2020-10-26 16:39 ` Topi Miettinen
2020-10-26 16:45 ` Florian Weimer
2020-10-27 14:22 ` Dave Martin
2020-10-27 14:41 ` Florian Weimer
2020-10-26 16:57 ` Szabolcs Nagy
2020-10-26 17:52 ` Dave Martin
2020-10-26 22:39 ` Jeremy Linton
2020-10-27 14:15 ` Dave Martin
2020-10-29 11:02 ` Catalin Marinas
2020-11-04 12:18 ` Dave Martin
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=3cb894d4-049f-aa25-4450-d1df36a1b92e@gmail.com \
--to=toiwoton@gmail.com \
--cc=Catalin.Marinas@arm.com \
--cc=broonie@kernel.org \
--cc=dave.martin@arm.com \
--cc=jeremy.linton@arm.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=s.mesoraca16@gmail.com \
--cc=systemd-devel@lists.freedesktop.org \
--cc=szabolcs.nagy@arm.com \
--cc=will.deacon@arm.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).