From: Dominique Martinet <asmadeus@codewreck.org>
To: Jeff Xu <jeffxu@google.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>,
Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <shuah@kernel.org>, Kees Cook <keescook@chromium.org>,
Daniel Verkamp <dverkamp@chromium.org>,
Christian Brauner <brauner@kernel.org>,
stable@vger.kernel.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 4/5] memfd: replace ratcheting feature from vm.memfd_noexec with hierarchy
Date: Wed, 16 Aug 2023 14:44:13 +0900 [thread overview]
Message-ID: <ZNxiLe_jkXpxh3QU@codewreck.org> (raw)
In-Reply-To: <CALmYWFvxLee5+RyLh=vo6kpwMVS-_C7BJ9kmTPDa2tetgHOHPw@mail.gmail.com>
Jeff Xu wrote on Tue, Aug 15, 2023 at 10:13:18PM -0700:
> > Given that it is possible for CAP_SYS_ADMIN users to create executable
> > binaries without memfd_create(2) and without touching the host
> > filesystem (not to mention the many other things a CAP_SYS_ADMIN process
> > would be able to do that would be equivalent or worse), it seems strange
> > to cause a fair amount of headache to admins when there doesn't appear
> > to be an actual security benefit to blocking this. There appear to be
> > concerns about confused-deputy-esque attacks[2] but a confused deputy that
> > can write to arbitrary sysctls is a bigger security issue than
> > executable memfds.
> >
> Something to point out: The demo code might be enough to prove your
> case in other distributions, however, in ChromeOS, you can't run this
> code. The executable in ChromeOS are all from known sources and
> verified at boot.
> If an attacker could run this code in ChromeOS, that means the
> attacker already acquired arbitrary code execution through other ways,
> at that point, the attacker no longer needs to create/find an
> executable memfd, they already have the vehicle. You can't use an
> example of an attacker already running arbitrary code to prove that
> disable downgrading is useless.
> I agree it is a big problem that an attacker already can modify a
> sysctl. Assuming this can happen by controlling arguments passed into
> sysctl, at the time, the attacker might not have full arbitrary code
> execution yet, that is the reason the original design is so
> restrictive.
I don't understand how you can say an attacker cannot run arbitrary code
within a process here, yet assert that they'd somehow run memfd_create +
execveat on it if this sysctl is lowered -- the two look equivalent to
me?
CAP_SYS_ADMIN is a kludge of a capability that pretty much gives root as
soon as you can run arbitrary code (just have a look at the various
container escape example when the capability is given); I see little
point in trying to harden just this here.
It'd make more sense to limit all sysctl modifications in the context
you're thinking of through e.g. selinux or another LSM.
(in the context of users making their own containers, my suggestion is
always to never use CAP_SYS_ADMIN, or if they must give it to a separate
minimal container where they can limit user interaction)
FWIW, I also think the proposed =2 behaviour makes more sense, but this
is something we already discussed last month so I won't come back to it
as not really involved here.
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2023-08-16 5:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 8:40 [PATCH v2 0/5] memfd: cleanups for vm.memfd_noexec Aleksa Sarai
2023-08-14 8:40 ` [PATCH v2 1/5] selftests: memfd: error out test process when child test fails Aleksa Sarai
2023-08-14 8:40 ` [PATCH v2 2/5] memfd: do not -EACCES old memfd_create() users with vm.memfd_noexec=2 Aleksa Sarai
2023-08-14 8:40 ` [PATCH v2 3/5] memfd: improve userspace warnings for missing exec-related flags Aleksa Sarai
2023-08-22 9:10 ` Christian Brauner
2023-09-01 5:13 ` Damian Tometzki
2023-09-02 22:58 ` Andrew Morton
2023-09-04 7:09 ` Aleksa Sarai
2023-09-05 16:20 ` Florian Weimer
2023-09-06 6:58 ` Aleksa Sarai
2023-08-14 8:41 ` [PATCH v2 4/5] memfd: replace ratcheting feature from vm.memfd_noexec with hierarchy Aleksa Sarai
2023-08-16 5:13 ` Jeff Xu
2023-08-16 5:44 ` Dominique Martinet [this message]
2023-08-16 22:46 ` Jeff Xu
2023-08-14 8:41 ` [PATCH v2 5/5] selftests: improve vm.memfd_noexec sysctl tests Aleksa Sarai
2023-08-16 5:08 ` [PATCH v2 0/5] memfd: cleanups for vm.memfd_noexec Jeff Xu
2023-08-19 2:50 ` Aleksa Sarai
2023-08-21 19:04 ` Jeff Xu
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=ZNxiLe_jkXpxh3QU@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=cyphar@cyphar.com \
--cc=dverkamp@chromium.org \
--cc=jeffxu@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).