linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Max Kellermann <max.kellermann@ionos.com>,
	Andy Lutomirski <luto@kernel.org>
Cc: serge@hallyn.com, paul@paul-moore.com, jmorris@namei.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] security/commoncap: don't assume "setid" if all ids are identical
Date: Sun, 9 Mar 2025 10:19:07 -0500	[thread overview]
Message-ID: <20250309151907.GA178120@mail.hallyn.com> (raw)
In-Reply-To: <20250306082615.174777-1-max.kellermann@ionos.com>

On Thu, Mar 06, 2025 at 09:26:15AM +0100, Max Kellermann wrote:
> If a program enables `NO_NEW_PRIVS` and sets up
> differing real/effective/saved/fs ids, the effective ids are
> downgraded during exec because the kernel believes it should "get no
> more than they had, and maybe less".
> 
> I believe it is safe to keep differing ids even if `NO_NEW_PRIVS` is
> set.  The newly executed program doesn't get any more, but there's no
> reason to give it less.
> 
> This is different from "set[ug]id/setpcap" execution where privileges
> may be raised; here, the assumption that it's "set[ug]id" if
> effective!=real is too broad.
> 
> If we verify that all user/group ids remain as they were, we can
> safely allow the new program to keep them.

Thanks, it's an interesting point.  Seems to mainly depend on what users
of the feature have come to expect.

Andy, what do you think?

> Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
> ---
>  security/commoncap.c | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 58a0c1c3e409..057a7400ef7d 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -861,6 +861,26 @@ static inline bool __is_setuid(struct cred *new, const struct cred *old)
>  static inline bool __is_setgid(struct cred *new, const struct cred *old)
>  { return !gid_eq(new->egid, old->gid); }
>  
> +/**
> + * Are all user/group ids in both cred instances identical?
> + *
> + * It can be used after __is_setuid() / __is_setgid() to check whether
> + * this is really a set*id operation or whether both processes just
> + * have differing real/effective ids.  It is safe to keep differing
> + * real/effective ids in "unsafe" program execution.
> + */
> +static bool has_identical_uids_gids(const struct cred *a, const struct cred *b)
> +{
> +	return uid_eq(a->uid, b->uid) &&
> +		gid_eq(a->gid, b->gid) &&
> +		uid_eq(a->suid, b->suid) &&
> +		gid_eq(a->sgid, b->sgid) &&
> +		uid_eq(a->euid, b->euid) &&
> +		gid_eq(a->egid, b->egid) &&
> +		uid_eq(a->fsuid, b->fsuid) &&
> +		gid_eq(a->fsgid, b->fsgid);
> +}
> +
>  /*
>   * 1) Audit candidate if current->cap_effective is set
>   *
> @@ -940,7 +960,8 @@ int cap_bprm_creds_from_file(struct linux_binprm *bprm, const struct file *file)
>  	 *
>  	 * In addition, if NO_NEW_PRIVS, then ensure we get no new privs.
>  	 */
> -	is_setid = __is_setuid(new, old) || __is_setgid(new, old);
> +	is_setid = (__is_setuid(new, old) || __is_setgid(new, old)) &&
> +		!has_identical_uids_gids(new, old);
>  
>  	if ((is_setid || __cap_gained(permitted, new, old)) &&
>  	    ((bprm->unsafe & ~LSM_UNSAFE_PTRACE) ||
> -- 
> 2.47.2

  parent reply	other threads:[~2025-03-09 15:28 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-06  8:26 [PATCH] security/commoncap: don't assume "setid" if all ids are identical Max Kellermann
2025-03-07 10:32 ` kernel test robot
2025-03-09 15:19 ` Serge E. Hallyn [this message]
2025-04-28 11:43   ` Max Kellermann
2025-05-06 13:21     ` Serge E. Hallyn
2025-05-06 14:51       ` Max Kellermann
2025-05-07  3:16         ` Andrew G. Morgan
2025-05-07  6:33           ` Max Kellermann
2025-05-08  3:32             ` Andrew G. Morgan
2025-05-08  6:38               ` Max Kellermann
2025-05-08  8:37               ` Max Kellermann
2025-05-09 17:50             ` Max Kellermann
2025-05-08 22:12         ` sergeh
2025-05-09  6:15           ` Max Kellermann
2025-05-09 14:44             ` Eric W. Biederman
2025-05-09 16:53               ` Max Kellermann
2025-05-09 20:17                 ` Serge E. Hallyn
2025-05-09 18:41               ` [PATCH] Documentation/no_new_privs.rst: document dropping effective ids Max Kellermann
2025-05-15 16:24 ` [PATCH] exec: Correct the permission check for unsafe exec Eric W. Biederman
2025-05-15 22:09   ` Kees Cook
2025-05-16 15:26     ` Eric W. Biederman
2025-05-16 18:06       ` Jann Horn
2025-05-16 18:08         ` Jann Horn
2025-05-16 21:46         ` sergeh
2025-05-20 22:38           ` Jann Horn
2025-05-20 22:43             ` Kees Cook
2025-05-16 23:29         ` Eric W. Biederman
2025-05-20 20:20           ` Kees Cook
2025-05-20 22:13             ` [PATCH v2] " Eric W. Biederman
2025-05-20 22:35               ` Kees Cook
2025-05-20 23:53               ` Jann Horn
2025-05-21 15:27                 ` Eric W. Biederman
2025-05-21 15:36                   ` Jann Horn
2025-06-11  0:18                     ` Paul Moore
2025-06-11 14:23                       ` Max Kellermann
2025-06-13 15:07                         ` Eric W. Biederman
2025-06-12 21:26                       ` Serge E. Hallyn
2025-06-13  1:48                         ` Kees Cook
2025-06-13 15:28                           ` Paul Moore
2025-06-16 19:57                             ` Kees Cook
2025-06-16 20:16                               ` Paul Moore
2025-05-16 21:48     ` [PATCH] " sergeh
2025-05-16 21:49   ` sergeh
     [not found] <CAKPOu+_p6D-s9k_rokup+7JC-GDJMCxweBrR2JthLGtSufrUCQ@mail.gmail.com>
     [not found] ` <20250509180150.GA707254@mail.hallyn.com>
     [not found]   ` <CAKPOu+_MEX-KC-Mp+Pn0=mKRoNQcrAs0nEUmyU84EZC=2CMkXA@mail.gmail.com>
     [not found]     ` <20250509192642.GA707808@mail.hallyn.com>
     [not found]       ` <CAKPOu+-iV8daKn_TVR5QStoBNWD-MDpG6Bmj4zoe4QQL_PLJtw@mail.gmail.com>
     [not found]         ` <20250510130938.GA712334@mail.hallyn.com>
     [not found]           ` <CAKPOu+_U6AAf5MTSi8mmUTbLdGEw0w=5mqnaCZ3YjvxgCN6WeA@mail.gmail.com>
     [not found]             ` <20250510160809.GA713084@mail.hallyn.com>
     [not found]               ` <CAKPOu+9ooP6yH6qHgAEaX_3W+kGxYjJX9UuTeGS_BPc3BhTDyA@mail.gmail.com>
     [not found]                 ` <20250510192919.GA714187@mail.hallyn.com>
     [not found]                   ` <202505121725.34FC22D2D@keescook>
2025-05-13  6:25                     ` [PATCH] security/commoncap: don't assume "setid" if all ids are identical Max Kellermann

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=20250309151907.GA178120@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=max.kellermann@ionos.com \
    --cc=paul@paul-moore.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).