From: Wander Lairson Costa <wander@redhat.com>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
Eric Biederman <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Laurent Vivier <laurent@vivier.eu>,
Wander Lairson Costa <wander@redhat.com>,
YunQiang Su <ysu@wavecomp.com>, Helge Deller <deller@gmx.de>,
Andrew Morton <akpm@linux-foundation.org>,
Jens Axboe <axboe@kernel.dk>, Alexey Gladkov <legion@kernel.org>,
David Hildenbrand <david@redhat.com>,
Rolf Eike Beer <eb@emlix.com>,
linux-fsdevel@vger.kernel.org (open list:FILESYSTEMS (VFS and
infrastructure)), linux-kernel@vger.kernel.org (open list)
Subject: [PATCH RFC v2 0/4] coredump: mitigate privilege escalation of process coredump
Date: Tue, 28 Dec 2021 14:09:04 -0300 [thread overview]
Message-ID: <20211228170910.623156-1-wander@redhat.com> (raw)
v2
==
Patch 02 conflicted with commit 92307383082d("coredump: Don't perform
any cleanups before dumping core") which I didn't have in my tree. V2
just changes the hunk
+#define PF_SUID 0x00000008
To
+#define PF_SUID 0x01000000
To merge cleanly. Other than that, it is the same patch as v1.
v1
==
A set-uid executable might be a vector to privilege escalation if the
system configures the coredump file name pattern as a relative
directory destiny. The full description of the vulnerability and
a demonstration of how we can exploit it can be found at [1].
This patch series adds a PF_SUID flag to the process in execve if it is
set-[ug]id binary and elevates the new image's privileges.
In the do_coredump function, we check if:
1) We have the SUID_FLAG set
2) We have CAP_SYS_ADMIN (the process might have decreased its
privileges)
3) The current directory is owned by root (the current code already
checks for core_pattern being a relative path).
4) non-privileged users don't have permission to write to the current
directory.
If all four conditions match, we set the need_suid_safe flag.
An alternative implementation (and more elegant IMO) would be saving
the fsuid and fsgid of the process in the task_struct before loading the
new image to the memory. But this approach would add eight bytes to all
task_struct instances where only a tiny fraction of the processes need
it and under a configuration that not all (most?) distributions don't
adopt by default.
Wander Lairson Costa (4):
exec: add a flag indicating if an exec file is a suid/sgid
process: add the PF_SUID flag
coredump: mitigate privilege escalation of process coredump
exec: only set the suid flag if the current proc isn't root
fs/coredump.c | 15 +++++++++++++++
fs/exec.c | 10 ++++++++++
include/linux/binfmts.h | 6 +++++-
include/linux/sched.h | 1 +
kernel/fork.c | 2 ++
5 files changed, 33 insertions(+), 1 deletion(-)
--
2.27.0
next reply other threads:[~2021-12-28 17:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-28 17:09 Wander Lairson Costa [this message]
2021-12-28 17:09 ` [PATCH RFC v2 1/4] exec: add a flag indicating if an exec file is a suid/sgid Wander Lairson Costa
2021-12-28 17:09 ` [PATCH RFC v2 2/4] process: add the PF_SUID flag Wander Lairson Costa
2021-12-28 17:09 ` [PATCH RFC v2 3/4] coredump: mitigate privilege escalation of process coredump Wander Lairson Costa
2021-12-28 17:09 ` [PATCH RFC v2 4/4] exec: only set the suid flag if the current proc isn't root Wander Lairson Costa
2022-01-03 22:11 ` [PATCH RFC v2 0/4] coredump: mitigate privilege escalation of process coredump Eric W. Biederman
2022-01-05 12:30 ` Wander Costa
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=20211228170910.623156-1-wander@redhat.com \
--to=wander@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=david@redhat.com \
--cc=deller@gmx.de \
--cc=dietmar.eggemann@arm.com \
--cc=eb@emlix.com \
--cc=ebiederm@xmission.com \
--cc=juri.lelli@redhat.com \
--cc=keescook@chromium.org \
--cc=laurent@vivier.eu \
--cc=legion@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=viro@zeniv.linux.org.uk \
--cc=ysu@wavecomp.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 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.