linux-fsdevel.vger.kernel.org archive mirror
 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>,
	YunQiang Su <ysu@wavecomp.com>,
	Laurent Vivier <laurent@vivier.eu>,
	Wander Lairson Costa <wander@redhat.com>,
	Helge Deller <deller@gmx.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Gladkov <legion@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	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 3/4] coredump: mitigate privilege escalation of process coredump
Date: Tue, 28 Dec 2021 14:09:07 -0300	[thread overview]
Message-ID: <20211228170910.623156-4-wander@redhat.com> (raw)
In-Reply-To: <20211228170910.623156-1-wander@redhat.com>

A set-uid executable might be a vector to a 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].

We now check if the core dump pattern is relative. If it is, then we
verify if root owns the current directory and if it does, we deny
writing the core file unless the directory is universally writable.

[1] https://www.openwall.com/lists/oss-security/2021/10/20/2

Signed-off-by: Wander Lairson Costa <wander@redhat.com>
---
 fs/coredump.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/fs/coredump.c b/fs/coredump.c
index a6b3c196cdef..26bea87af153 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -514,6 +514,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
 	struct core_name cn;
 	struct mm_struct *mm = current->mm;
 	struct linux_binfmt * binfmt;
+	struct inode *pwd_inode;
 	const struct cred *old_cred;
 	struct cred *cred;
 	int retval = 0;
@@ -559,6 +560,20 @@ void do_coredump(const kernel_siginfo_t *siginfo)
 		need_suid_safe = true;
 	}
 
+	/*
+	 * If we are a set-uid/gid root process and the current directory is
+	 * owned by root but not universally writable, prohibit dumps under
+	 * this path.
+	 *
+	 * Mitigate https://www.openwall.com/lists/oss-security/2021/10/20/2
+	 */
+	pwd_inode = current->fs->pwd.dentry->d_inode;
+	if (current->flags & PF_SUID &&
+	    capable(CAP_SYS_ADMIN) &&
+	    uid_eq(pwd_inode->i_uid, GLOBAL_ROOT_UID) &&
+	    !(pwd_inode->i_mode & 0002))
+		need_suid_safe = true;
+
 	retval = coredump_wait(siginfo->si_signo, &core_state);
 	if (retval < 0)
 		goto fail_creds;
-- 
2.27.0


  parent reply	other threads:[~2021-12-28 17:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-28 17:09 [PATCH RFC v2 0/4] coredump: mitigate privilege escalation of process coredump Wander Lairson Costa
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 ` Wander Lairson Costa [this message]
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-4-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 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).