Re: [PATCH] exec: Correct the permission check for unsafe exec

["Eric W. Biederman" <ebiederm@xmission.com>]

Kees Cook <kees@kernel.org> writes:

> On Thu, May 15, 2025 at 11:24:47AM -0500, Eric W. Biederman wrote:
>> I have condensed the logic from Linux-2.4.0-test12 to just:
>> 	id_changed = !uid_eq(new->euid, old->euid) || !in_group_p(new->egid);
>> 
>> This change is userspace visible, but I don't expect anyone to care.
>> [...]
>> -static inline bool __is_setuid(struct cred *new, const struct cred *old)
>> -{ return !uid_eq(new->euid, old->uid); }
>> -
>> -static inline bool __is_setgid(struct cred *new, const struct cred *old)
>> -{ return !gid_eq(new->egid, old->gid); }
>> -
>> [...]
>> -	is_setid = __is_setuid(new, old) || __is_setgid(new, old);
>> +	id_changed = !uid_eq(new->euid, old->euid) || !in_group_p(new->egid);
>
> The core change here is testing for differing euid rather than
> mismatched uid/euid. (And checking for egid in the set of all groups.)

Yes.

For what the code is trying to do I can't fathom what was trying to
be accomplished by the "mismatched" uid/euid check.

> Imagined situations:
>
> - setuid process is sharing fs. We already believe this is a non-issue,
>   as Jann pointed out about Chrome's order of operations, so so changes
>   here are likely fine.

Yes, nothing has changed from a security standpoint.

> - somehow ptracing a process with uid!=euid, and it tries to exec a
>   different setuid==euid ELF. Is switching ELF images a security
>   boundary? Probably not realistically.

The concern with tracing is can the tracer gain more privileges from
the traced application.  If there is no switch of euid or egid the
answer is no.

In fact what we do is actively bad in the ptrace case as it makes
debugging unnecessarily change the behavior of an application.

> - setuid process sets NNP and execs a setuid==euid ELF, expecting to
>   have euid stripped. That doesn't happen any more. This is the most
>   worrisome case, but a program like that should _really_ have dropped
>   euid first if it is depending on that behavior. Hmmm. Probably some
>   code searching is needed...

That is a fair question.  Has some no-new-privs using application
that has uid != euid when it calls exec developed a dependency on
how we the code sets euid == uid when we call exec today.

That is exactly the case that Max Kellermann has a problem with,
so we have at least one no-new-privs user that wants the fixed behavior.

In addition to code searching we could first change the behavior for
everything except ptrace to just return -EPERM.  That should flush out
most of the users of this case if we miss some one.

Given that I have only seen a justification for limping along during
ptrace from Linus (and it was a long time ago) I think we would be
better off just making it fail, and then we don't have to worry
about userspace depending upon this weird case in future maintenance.

Eric