Date: Sat, 29 Apr 1995 15:33:19 +0400 From: "Andrey A. Chernov, Black Mage" <ache@astral.msk.su> To: Bruce Evans <bde@zeta.org.au>, sa2c@and.or.jp Cc: security@FreeBSD.org, "Garrett A. Wollman" <wollman@lcs.mit.edu> Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc Message-ID: <pM_FYel4m3@astral.msk.su> In-Reply-To: <199504290814.SAA16098@godzilla.zeta.org.au>; from Bruce Evans at Sat, 29 Apr 1995 18:14:04 %2B1000 References: <199504290814.SAA16098@godzilla.zeta.org.au>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?pM_FYel4m3>