From owner-freebsd-security Sat Apr 29 05:12:02 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA23906 for security-outgoing; Sat, 29 Apr 1995 05:12:02 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA23898 for ; Sat, 29 Apr 1995 05:11:52 -0700 Received: by sequent.kiae.su id AA24454 (5.65.kiae-2 ); Sat, 29 Apr 1995 15:51:19 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 29 Apr 95 15:51:17 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id PAA00941; Sat, 29 Apr 1995 15:33:20 +0400 To: Bruce Evans , sa2c@and.or.jp Cc: security@FreeBSD.org, "Garrett A. Wollman" References: <199504290814.SAA16098@godzilla.zeta.org.au> In-Reply-To: <199504290814.SAA16098@godzilla.zeta.org.au>; from Bruce Evans at Sat, 29 Apr 1995 18:14:04 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Sat, 29 Apr 1995 15:33:19 +0400 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc Lines: 52 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2548 Sender: security-owner@FreeBSD.org Precedence: bulk In message <199504290814.SAA16098@godzilla.zeta.org.au> Bruce Evans writes: [wrong fix skipped] >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. I recently commit SAVED_IDS change which conforms POSIX here. >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. 0) Now we have _all_ set*[gu]id() functions in the same way like SunOS (SunOS is de-facto standard, most of Unix pgms expects its way). SunOS have true POSIX SAVED_IDS setuid()/setgid() and BSD4.2-like setre*(). Moreover, now we compatible with Linux setuid()/setgid(), they have POSIX SAVED_IDS too. I think current scheme is the best way which is possible. 1) seteuid() does not change svuid according to SunOS. >From common sense it allows root to keep svuid untouched, I remember some recent Garrett words about it. 2) There is _no_ programs found which expects BSD4.4 setre*() because: (1) implementation _completely_ broken (they have internal static variable to mimic svuid which is true security hole), (2) setre*() treated as depricated in BSD4.4, so no new BSD4.4 oriented pgms expects it. 3) I don't see sec hole you point: root: seteuid(uid1) --> euid=uid1 ruid=x1 svuid=x2 become non-root: setuid(here can be only x1 or x2), so --> euid=x1 or x2 ruid=x1 svuid=x2 it is equivalent of: seteuid(x1 or x2), it is possible even in old variant. where is the hole? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849