All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.