From: ebiederm@xmission.com (Eric W. Biederman)
To: Waiman Long <longman@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Kees Cook <keescook@chromium.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Laurent Vivier <laurent@vivier.eu>,
YunQiang Su <ysu@wavecomp.com>, Helge Deller <deller@gmx.de>
Subject: Re: [PATCH] exec: Make suid_dumpable apply to SUID/SGID binaries irrespective of invoking users
Date: Tue, 21 Dec 2021 09:55:55 -0600 [thread overview]
Message-ID: <87lf0e7y0k.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20211221021744.864115-1-longman@redhat.com> (Waiman Long's message of "Mon, 20 Dec 2021 21:17:44 -0500")
Waiman Long <longman@redhat.com> writes:
> The begin_new_exec() function checks for SUID or SGID binaries by
> comparing effective uid and gid against real uid and gid and using
> the suid_dumpable sysctl parameter setting only if either one of them
> differs.
>
> In the special case that the uid and/or gid of the SUID/SGID binaries
> matches the id's of the user invoking it, the suid_dumpable is not
> used and SUID_DUMP_USER will be used instead. The documentation for the
> suid_dumpable sysctl parameter does not include that exception and so
> this will be an undocumented behavior.
>
> Eliminate this undocumented behavior by adding a flag in the linux_binprm
> structure to designate a SUID/SGID binary and use it for determining
> if the suid_dumpable setting should be applied or not.
I see that you are making the code match the documentation.
What harm/problems does this mismatch cause in practice?
What is the motivation for this change?
I am trying to see the motivation but all I can see is that
in the case where suid and sgid do nothing in practice the code
does not change dumpable. The point of dumpable is to refuse to
core dump when it is not safe. In this case since nothing happened
in practice it is safe.
So how does this matter in practice. If there isn't a good
motivation my feel is that it is the documentation that needs to be
updated rather than the code.
There are a lot of warts to the suid/sgid handling during exec. This
just doesn't look like one of them.
Eric
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> fs/exec.c | 6 +++---
> include/linux/binfmts.h | 5 ++++-
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/fs/exec.c b/fs/exec.c
> index 537d92c41105..60e02e678fb6 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1344,9 +1344,7 @@ int begin_new_exec(struct linux_binprm * bprm)
> * is wrong, but userspace depends on it. This should be testing
> * bprm->secureexec instead.
> */
> - if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP ||
> - !(uid_eq(current_euid(), current_uid()) &&
> - gid_eq(current_egid(), current_gid())))
> + if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP || bprm->is_sugid)
> set_dumpable(current->mm, suid_dumpable);
> else
> set_dumpable(current->mm, SUID_DUMP_USER);
> @@ -1619,11 +1617,13 @@ static void bprm_fill_uid(struct linux_binprm *bprm, struct file *file)
> if (mode & S_ISUID) {
> bprm->per_clear |= PER_CLEAR_ON_SETID;
> bprm->cred->euid = uid;
> + bprm->is_sugid = 1;
> }
>
> if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
> bprm->per_clear |= PER_CLEAR_ON_SETID;
> bprm->cred->egid = gid;
> + bprm->is_sugid = 1;
> }
> }
>
> diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
> index 049cf9421d83..6d9893c59085 100644
> --- a/include/linux/binfmts.h
> +++ b/include/linux/binfmts.h
> @@ -41,7 +41,10 @@ struct linux_binprm {
> * Set when errors can no longer be returned to the
> * original userspace.
> */
> - point_of_no_return:1;
> + point_of_no_return:1,
> +
> + /* Is a SUID or SGID binary? */
> + is_sugid:1;
> #ifdef __alpha__
> unsigned int taso:1;
> #endif
next prev parent reply other threads:[~2021-12-21 15:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 2:17 [PATCH] exec: Make suid_dumpable apply to SUID/SGID binaries irrespective of invoking users Waiman Long
2021-12-21 15:55 ` Eric W. Biederman [this message]
2021-12-21 16:41 ` Waiman Long
2021-12-21 17:35 ` Eric W. Biederman
2021-12-21 18:01 ` Waiman Long
2021-12-21 18:19 ` Linus Torvalds
2021-12-21 19:27 ` Waiman Long
2021-12-21 20:56 ` Willy Tarreau
2021-12-21 22:13 ` Willy Tarreau
2021-12-21 23:35 ` Eric W. Biederman
2021-12-22 6:29 ` Willy Tarreau
2021-12-26 15:03 ` Willy Tarreau
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=87lf0e7y0k.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=deller@gmx.de \
--cc=keescook@chromium.org \
--cc=laurent@vivier.eu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--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