"Andrey A. Chernov" wrote:
> Newly introduced seresuid call add security hole too. Compare following
> checks. First one comes from
>
> setreuid:
>
> if (((ruid != (uid_t)-1 && ruid != pc->p_ruid && ruid != pc->p_svuid) |
|
> (euid != (uid_t)-1 && euid != pc->pc_ucred->cr_uid &&
> euid != pc->p_ruid && euid != pc->p_svuid)) &&
>
> setresuid:
>
> if (((ruid != (uid_t)-1 && ruid != pc->p_ruid && ruid != pc->p_svuid &&
> ruid != pc->pc_ucred->cr_uid) ||
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> (euid != (uid_t)-1 && euid != pc->p_ruid && euid != pc->p_svuid &&
> euid != pc->pc_ucred->cr_uid) ||
> (suid != (uid_t)-1 && suid != pc->p_ruid && suid != pc->p_svuid &&
> suid != pc->pc_ucred->cr_uid)) &&
>
> As I see you can now additionly set ruid to euid which is not allowed in
> setreuid call. Supposed POSIX_APPENDIX_B_4_2_2 clause should be either ifdefe
d
> or removed as in setreuid.
.. and why is this a security hole? setresuid(geteuid(), geteuid(), geteuid())
is equivalent to setuid(geteuid())..
For what it's worth, this is the Linux version:
if ((ruid != (uid_t) -1) && (ruid != current->uid) &&
(ruid != current->euid) && (ruid != current->suid))
return -EPERM;
if ((euid != (uid_t) -1) && (euid != current->uid) &&
(euid != current->euid) && (euid != current->suid))
return -EPERM;
if ((suid != (uid_t) -1) && (suid != current->uid) &&
(suid != current->euid) && (suid != current->suid))
return -EPERM;
.. which is functionally equivalent to what we have.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
