From: Wander Costa <wcosta@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Wander Lairson Costa <wander@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
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>,
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>,
"open list:FILESYSTEMS (VFS and infrastructure)"
<linux-fsdevel@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Waiman Long <longman@redhat.com>, Willy Tarreau <w@1wt.eu>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH RFC v2 0/4] coredump: mitigate privilege escalation of process coredump
Date: Wed, 5 Jan 2022 09:30:33 -0300 [thread overview]
Message-ID: <CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com> (raw)
In-Reply-To: <87ilv0mput.fsf@email.froward.int.ebiederm.org>
On Mon, Jan 3, 2022 at 7:54 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Wander Lairson Costa <wander@redhat.com> writes:
>
> Have you seen the discussion at:
> https://lkml.kernel.org/r/20211221021744.864115-1-longman@redhat.com
> ?
>
No, I wasn't aware of this, thanks.
> Adding a few people from that conversation.
>
> > 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.
>
> Which is a slightly different approach than we have discussed
> previously.
>
> Something persistent to mark the processes descended from the suid exec
> is something commonly agreed upon.
>
> How we can dump core after that (with the least disruption is the
> remaining question).
>
> You would always allow coredumps unless the target directory is
> problematic. I remember it being suggested that even dumping to a pipe
> might not be safe in practice. Can someone remember why?
>
> The other approach we have discussed is simply not allowing coredumps
> unless the target process takes appropriate action to reenable them.
>
> Willy posted a patch to that effect.
>
>
> From a proof of concept perspective PF_SUID and your directory checks look
> like fine. From a production implementation standpoint I think we would
> want to make them a bit more general. PF_SUID because it is more than
> uid changes that can grant privilege during exec. We especially want to
> watch out for setcap executables. The directory checks similarly look
> very inflexible. I think what we want is to test if the process before
> the privilege change of the exec could write to the directory.
>
> Even with your directory test approach you are going to run into
> the semi-common idio of becomming root and then starting a daemon
> in debugging mode so you can get a core dump.
>
> > 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.
>
> One possibility is to save a struct cred on the mm_struct. If done
> carefully I think that would allow commit_creds to avoid the need
> for dumpability changes (there would always be enough information to
> directly compute it).
>
> I can see that working for detecting dropped privileges. I don't know
> if that would work for raised privileges.
>
> Definitely focusing in on the mm_struct for where to save the needed
> information seems preferable, as in general it is an mm property not a
> per task property.
>
After reading the other thread and your comments, I came up with the
following idea:
- Create fields coredump_uid and coredump_gid in the mm_struct
- At fork time, copy the euid and egid to coredump_uid and coredump_gid.
- Only change coredump_uid/coredump_gid when the process changes its euid/egid.
- The do_coredump function already creates a local creds struct.
Change the code to set
its fsuid and fsgid to coredump_uid and coredump_gid.
This solution still has the inconvenience that a suid daemon probably
won't have the permission to
core dump by default. We can fix this by changing the setsid system
call to assign coredump_uid and coredump_gid
to euid and egid.
If it sounds reasonable, I can give this idea a try.
> Eric
>
>
>
> > 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(-)
>
prev parent reply other threads:[~2022-01-05 12:30 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 ` [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 [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=CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com \
--to=wcosta@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=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=vincent.guittot@linaro.org \
--cc=viro@zeniv.linux.org.uk \
--cc=w@1wt.eu \
--cc=wander@redhat.com \
--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).