From: Giuseppe Scrivano <gscrivan@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: keescook@chromium.org, bristot@redhat.com, ebiederm@xmission.com,
brauner@kernel.org, cyphar@cyphar.com, viro@zeniv.linux.org.uk,
walters@verbum.org, avagin@gmail.com, alexl@redhat.com,
peterz@infradead.org, bmasney@redhat.com
Subject: Re: [PATCH v4 1/3] exec: add PR_HIDE_SELF_EXE prctl
Date: Tue, 14 Mar 2023 10:44:34 +0100 [thread overview]
Message-ID: <87o7ovlla5.fsf@redhat.com> (raw)
In-Reply-To: <20230310112554.1261731-1-gscrivan@redhat.com> (Giuseppe Scrivano's message of "Fri, 10 Mar 2023 12:25:52 +0100")
Giuseppe Scrivano <gscrivan@redhat.com> writes:
> This patch adds a new prctl called PR_HIDE_SELF_EXE which allows
> processes to hide their own /proc/self/exe file. When this prctl is
> used, every access to /proc/self/exe for the calling process will
> fail with EPERM.
>
> This is useful for preventing issues like CVE-2019-5736, where an
> attacker can gain host root access by overwriting the binary
> in OCI runtimes through file-descriptor mishandling in containers.
>
> The current fix for CVE-2019-5736 is to create a read-only copy or
> a bind-mount of the current executable, and then re-exec the current
> process. With the new prctl, the read-only copy or bind-mount copy is
> not needed anymore.
>
> Once prctl(PR_HIDE_SELF_EXE) is set, it will blocks PR_SET_DUMPABLE to
> be set again. It is not done automatically so that PR_SET_DUMPABLE
> can be set at a later time if needed, e.g. a container runtime might
> want to do that after the user namespace is joined.
>
> It is currently kind of expected that a container uses execve to pass
> control to a binary in the container chroot, since the /proc/self/exe
> and /proc/self/map_files refer to files that are not part of the
> container itself; so if the process can be compromised in any way
> (e.g. an interpreter running a script in the container without calling
> execve), it could potentially lead to host compromise. It is
> necessary to ensure that the current process cannot be set to dumpable
> anymore, since that would allow another process in the container to
> get access to its proc files.
>
> A container runtime could use the new prctl in the following way:
>
> - run prctl(PR_HIDE_SELF_EXE) as soon as possible.
> - if prctl(PR_HIDE_SELF_EXE) fails then use the more expensive current
> fallbacks mechanism.
> - perform all operations that require the process to be dumpable.
> - prctl(PR_SET_DUMPABLE, 0), as it is already done today.
> - execve the new binary or run directly the interpreter.
>
> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
> ---
> v3: https://lkml.org/lkml/2023/1/20/434
>
> Differences from v3:
>
> - rebased on top of the latest upstream master.
> - now prctl(PR_HIDE_SELF_EXE) blocks access only from the same thread group, it
> won't break CRIU as v3 did.
> - extend the prctl to also cover files under /proc/self/map_files.
> - once prctl(PR_HIDE_SELF_EXE) is used, it is not possible to unset
> SUID_DUMP_DISABLE anymore. This is useful for the case where the container
> doesn't use execve to pass the control to a binary in the container chroot, and it
> prevents the process to be set to dumpable again since it would allow a different
> process in the container to get access to its proc files.
> - cleaned up the selftest and added more checks.
I've done a mistake in this version of the patchset, so please everyone just ignore it.
prev parent reply other threads:[~2023-03-14 9:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 11:25 [PATCH v4 1/3] exec: add PR_HIDE_SELF_EXE prctl Giuseppe Scrivano
2023-03-10 11:25 ` [PATCH v4 2/3] exec: PR_HIDE_SELF_EXE hides /proc/self/map_files Giuseppe Scrivano
2023-03-10 11:25 ` [PATCH v4 3/3] selftests: add tests for prctl(SET_HIDE_SELF_EXE) Giuseppe Scrivano
2023-03-14 9:44 ` Giuseppe Scrivano [this message]
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=87o7ovlla5.fsf@redhat.com \
--to=gscrivan@redhat.com \
--cc=alexl@redhat.com \
--cc=avagin@gmail.com \
--cc=bmasney@redhat.com \
--cc=brauner@kernel.org \
--cc=bristot@redhat.com \
--cc=cyphar@cyphar.com \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=viro@zeniv.linux.org.uk \
--cc=walters@verbum.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 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.