Date: Sat, 29 Apr 1995 18:14:04 +1000 From: Bruce Evans <bde@zeta.org.au> To: ache@astral.msk.su, sa2c@and.or.jp Cc: security@FreeBSD.org Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc Message-ID: <199504290814.SAA16098@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Hmm... I've tried to hack set[ug]id() to check saved id like >setre[ug]id(). Does this hack violate POSIX standard? It would if you don't change the headers and sysconf() to give the correct value for _POSIX_SAVED_IDS :-). >--- kern_prot.c.orig Sat Apr 29 11:18:29 1995 >+++ kern_prot.c Sat Apr 29 11:21:15 1995 >@@ -262,6 +262,7 @@ setuid(p, uap, retval) > > uid = uap->uid; > if (uid != pc->p_ruid && >+ uid != pc->p_svuid && > (error = suser(pc->pc_ucred, &p->p_acflag))) > return (error); > /* >@@ -322,7 +323,9 @@ setgid(p, uap, retval) > int error; > > gid = uap->gid; >- if (gid != pc->p_rgid && (error = suser(pc->pc_ucred, &p->p_acflag))) >+ if (gid != pc->p_rgid && >+ gid != pc->p_svgid && >+ (error = suser(pc->pc_ucred, &p->p_acflag))) > return (error); > pc->pc_ucred = crcopy(pc->pc_ucred); > pc->pc_ucred->cr_groups[0] = gid; >-- This violates POSIX in more serious ways: if POSIX saved ids are implemented, then setuid() by non-root doesn't change the ruid or the svuid and setgid() by non-root doesn't change the rgid or the svgid. There are other problems. setreuid(-1, euid) is different from seteuid(euid) because the former is more careful about the svuid. I think this is too surprising. Since seteuid() doesn't change the svuid, if POSIX saved ids are enabled, then setuid() by non-root after seteuid() by root is a possible security hole (the svuid hasn't been given up). Of course, the POSIX setuid() shouldn't be mixed with the BSD seteuid(), but programs probably do it. OTOH, changing setreuid() to be like the recently changed setreuid() may break all the BSD4.4 programs that were less recently changed to assume the 4.4 semantics for seteuid(). It was probably OK to change setreuid() because it is deprecated and BSD4.4 programs shouldn't use it, while BSD4.3 programs want the old semantics. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504290814.SAA16098>