From owner-freebsd-security  Sat Apr 29 01:18:55 1995
Return-Path: security-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id BAA15062
          for security-outgoing; Sat, 29 Apr 1995 01:18:55 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA15052
          for <security@FreeBSD.org>; Sat, 29 Apr 1995 01:18:27 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA16098; Sat, 29 Apr 1995 18:14:04 +1000
Date: Sat, 29 Apr 1995 18:14:04 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199504290814.SAA16098@godzilla.zeta.org.au>
To: ache@astral.msk.su, sa2c@and.or.jp
Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc
Cc: security@FreeBSD.org
Sender: security-owner@FreeBSD.org
Precedence: bulk

>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