Author: Phil Pennock Date: To: Ted Cooper CC: exim-users Subject: Re: [exim] static code analyze for exim-4.72
On 2010-11-20 at 07:41 +1000, Ted Cooper wrote: > real_uid = getuid();
> real_gid = getgid();
>
> if (real_uid == root_uid)
> {
> setgid(real_gid); /* root cannot fail at this */
> setuid(real_uid); /* or this */
> }
Hrm. My recollection is that root *can* fail at these, on a system with
process capabilities where the process no longer has the CAP_SETUID
capability, and that this check resulted in a Sendmail security flaw.
However, for that to happen, the CAP_SETUID would have to *not* block
the fact that the program executable was marked setuid, and setuid would
have to not re-grant those privileges, so this was only an issue on some
buggy old Linux kernels.
Nonetheless, the problem has occurred in the past and will therefore
recur in the future on some other shiny poorly thought through attempt
to change the Unix security model and it would be good to be defensive
here.
FWIW, I'm happy to see someone experimenting with C-lang and its tools.
The compiler market needs more competition. Fortunately, PH wrote Exim
without assuming that CC=gcc, only having gcc as the default.
> Or can it fail? If root ran the program when it was setuid to some other
> user with too many processes already?
Yes, on Linux setuid will fail with errno set to EAGAIN in such a case.
FreeBSD only documents EPERM; however, it can fail if MAC rules say so,
or PRIV_CRED_SETUID is missing (in various ways). The
security.bsd.suser_enabled sysctl is true by default, so uid 0 has
privileges anyway. Jails don't affect PRIV_CRED_SETUID. So it's just
down to the MAC policies. AFAIK, there are currently no policies which
affect this, but I could be wrong.
