From owner-freebsd-security Mon Apr 24 02:12:46 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA28193 for security-outgoing; Mon, 24 Apr 1995 02:12:46 -0700 Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id CAA28186 for ; Mon, 24 Apr 1995 02:12:41 -0700 Received: from muffit.reo.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA00985; Mon, 24 Apr 95 02:07:54 -0700 Received: by muffit.reo.dec.com (5.65/helenc-6Apr93); id AA09374; Mon, 24 Apr 1995 10:11:17 +0100 From: erandall@muffit.reo.dec.com (Ed Randall) Message-Id: <9504240911.AA09374@muffit.reo.dec.com> Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Mon, 24 Apr 95 10:11:16 WET DST Cc: freebsd-security@FreeBSD.org In-Reply-To: <9504211549.AA06954@halloran-eldar.lcs.mit.edu>; from "Garrett Wollman" at Apr 21, 95 11:49 am X-Mailer: ELM [version 2.3 PL11] Sender: security-owner@FreeBSD.org Precedence: bulk Hi Garrett, Garrett Wollman writes: > > < > > Wouldn't it be better to FIX these functions to match the POSIX standard, and > > patch up the security holes ? > > The POSIX standard specifies set[ug]id() AND NOTHING ELSE. Do you > really want strict POSIX behavior? > > I didn't think so... Sorry, I stand corrected; I'm not an expert on POSIX, and I don't even own a copy of it. But I got the impression that we had a load of stuff here that was about to be chopped without consideration for actually fixing it first, with unknown repercussions ... I'm all for standards compliance, it makes portability SO much easier. And while I'm about it, hats off to HP for being the only major UNIX that actually states in its manual pages, exactly what standard their API conforms to; I wish everyone else would do it. But no, I don't think that "legacy" functions that are outside of a standard should be removed for that reason alone; If they are broken in some way, they should be fixed; If they are broken so badly that for example the mere _specification_ of them is a security hole, then yes, there is a case for removing them, and fixing any applications that make use of them, to do it the "proper" way. The manual pages should state exactly what standards they conform to, if any, and whether or not they are obsolete and may not be supported in future releases. What are your views on the subject ? BTW, do you happen to know if there is a URL where I can get access to the full POSIX spec ? Regards, Ed ---- ---------------------------------------------------------------------- Ed Randall Digital Equipment Co.Ltd., Worton Grange, Reading DECnet : RDGENG::RANDALL Internal phone : 7-830-4712 Internet : erandall@muffit.reo.dec.com Telephone: (01734) 204712 ---------------------------------------------------------------------- Speaking for myself, not for Digital or anybody else. From owner-freebsd-security Tue Apr 25 22:10:28 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA06896 for security-outgoing; Tue, 25 Apr 1995 22:10:28 -0700 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA06888 for ; Tue, 25 Apr 1995 22:10:20 -0700 Received: from s1.elec.uq.oz.au by bunyip.cc.uq.oz.au with SMTP (PP); Wed, 26 Apr 1995 15:09:58 +1000 Received: from s4 (s4.elec.uq.oz.au) by s1.elec.uq.oz.au (4.0/SMI-4.0) id AA15058; Wed, 26 Apr 95 15:09:34 EST From: clary@elec.uq.oz.au (Clary Harridge) Message-Id: <9504260509.AA15058@s1.elec.uq.oz.au> Subject: DISKLESS users become root To: freebsd-security@FreeBSD.org Date: Wed, 26 Apr 1995 15:08:47 +1000 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 760 Sender: security-owner@FreeBSD.org Precedence: bulk Users on any DISKLESS client can become root during the boot sequence. I have diskless clients booting off a FreeBSD file server and find that Pressing CTRLC just after the last NFS mount and before the "autoreboot" message causes init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter pathname of shell or RETURN for sh: then RETURN gives a root shell. The state of the /etc/ttys file is not being checked for whether the console is secure (or not) and the user is NOT prompted for a root password. Has anyone a cure for this problem? -- regards Dept. of Electrical Engineering, Clary Harridge University of Queensland, QLD, Australia, 4072 Phone: +61-7-365-3636 Fax: +61-7-365-4999 INTERNET: clary@elec.uq.oz.au From owner-freebsd-security Wed Apr 26 08:39:36 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA14337 for security-outgoing; Wed, 26 Apr 1995 08:39:36 -0700 Received: from pluto.ops.NeoSoft.com (root@pluto.ops.NeoSoft.COM [198.64.212.23]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA14330 for ; Wed, 26 Apr 1995 08:39:34 -0700 Received: from metal.ops.neosoft.com (root@glenn-slip41.nmt.edu [129.138.5.141]) by pluto.ops.NeoSoft.com (8.6.10/8.6.10) with ESMTP id KAA00266; Wed, 26 Apr 1995 10:39:30 -0500 Received: (from smace@localhost) by metal.ops.neosoft.com (8.6.11/8.6.10) id JAA01305; Wed, 26 Apr 1995 09:21:21 -0600 From: Scott Mace Message-Id: <199504261521.JAA01305@metal.ops.neosoft.com> Subject: Re: DISKLESS users become root To: clary@elec.uq.oz.au (Clary Harridge) Date: Wed, 26 Apr 1995 09:21:20 -0600 (MDT) Cc: freebsd-security@FreeBSD.org In-Reply-To: <9504260509.AA15058@s1.elec.uq.oz.au> from "Clary Harridge" at Apr 26, 95 03:08:47 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 818 Sender: security-owner@FreeBSD.org Precedence: bulk I think if you make console in /etc/ttys be insecure, it will solve you problem. This is require the root password to go into single user mode. Without this, the console is a very insecure place... Scott > > Users on any DISKLESS client can become root during the boot sequence. > > I have diskless clients booting off a FreeBSD file server and find that > > Pressing CTRLC just after the last NFS mount and before the "autoreboot" > message causes > > init: /bin/sh on /etc/rc terminated abnormally, going to single user mode > Enter pathname of shell or RETURN for sh: > > then > > RETURN gives a root shell. > > The state of the /etc/ttys file is not being checked for whether the > console is secure (or not) and the user is NOT prompted for a root > password. > > Has anyone a cure for this problem? From owner-freebsd-security Wed Apr 26 17:15:10 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA02536 for security-outgoing; Wed, 26 Apr 1995 17:15:10 -0700 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA02519 for ; Wed, 26 Apr 1995 17:14:18 -0700 Received: from s1.elec.uq.oz.au by bunyip.cc.uq.oz.au with SMTP (PP); Thu, 27 Apr 1995 10:13:07 +1000 Received: from s4 (s4.elec.uq.oz.au) by s1.elec.uq.oz.au (4.0/SMI-4.0) id AA10823; Thu, 27 Apr 95 10:12:44 EST From: clary@elec.uq.oz.au (Clary Harridge) Message-Id: <9504270012.AA10823@s1.elec.uq.oz.au> Subject: Re: DISKLESS users become root To: smace@metal-mail.neosoft.com (Scott Mace) Date: Thu, 27 Apr 1995 10:11:57 +1000 (EST) Cc: freebsd-security@FreeBSD.org In-Reply-To: <199504261521.JAA01305@metal.ops.neosoft.com> from "Scott Mace" at Apr 26, 95 09:21:20 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 714 Sender: security-owner@FreeBSD.org Precedence: bulk > > I think if you make console in /etc/ttys be insecure, it will solve > you problem. This is require the root password to go into single > user mode. Without this, the console is a very insecure place... > > Scott Thanks Scott but No I am afraid that is not the problem. Whether the console is secure or insecure makes no difference. init receives the SIGINT and prompts for a shell only It as if the define "SECURE" was undefined during the build of /sbin/init but I can see that it is defined in the Makefile. -- regards Dept. of Electrical Engineering, Clary Harridge University of Queensland, QLD, Australia, 4072 Phone: +61-7-365-3636 Fax: +61-7-365-4999 INTERNET: clary@elec.uq.oz.au From owner-freebsd-security Thu Apr 27 21:40:29 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA28010 for security-outgoing; Thu, 27 Apr 1995 21:40:29 -0700 Received: from news.rim.or.jp (news.rim.or.jp [202.255.181.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA28004 for ; Thu, 27 Apr 1995 21:40:25 -0700 Received: (from uucp@localhost) by news.rim.or.jp (8.6.10+2.4W/3.3W-rim1.0) with UUCP id NAA06252 for security@FreeBSD.org; Fri, 28 Apr 1995 13:40:22 +0900 Received: from us.and.or.jp (localhost [127.0.0.1]) by us.and.or.jp (8.6.11/3.3W8) with ESMTP id NAA00812 for ; Fri, 28 Apr 1995 13:36:15 +0900 Message-Id: <199504280436.NAA00812@us.and.or.jp> Reply-To: sa2c@st.rim.or.jp To: security@FreeBSD.org Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc Date: Fri, 28 Apr 1995 13:36:14 +0900 From: NIIMI Satoshi Sender: security-owner@FreeBSD.org Precedence: bulk I've noticed with -current that when euid is not equal to ruid, setuid(euid) fails but setreuid(euid, euid) successes. But once setreuid(euid, -1) or setreuid(euid, euid), setuid(euid) sccesses. Please unify the rule for setre[ug]id() and set[ug]id(): a) It is possible to change ruid if target is same as saved uid. or b) Only the superuser can change ruid. IMHO: There is no need to give users the pass to change real user id. The main aim of setre[ug]id() in 4.3BSD was to change e[ug]id. This can be done by only sete[ug]id() in 4.4BSD. -- NIIMI Satoshi From owner-freebsd-security Fri Apr 28 08:48:50 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA16858 for security-outgoing; Fri, 28 Apr 1995 08:48:50 -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 IAA16852 for ; Fri, 28 Apr 1995 08:48:46 -0700 Received: by sequent.kiae.su id AA06827 (5.65.kiae-2 ); Fri, 28 Apr 1995 19:41:34 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 28 Apr 95 19:41:33 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id TAA00794; Fri, 28 Apr 1995 19:39:43 +0400 To: sa2c@st.rim.or.jp, security@FreeBSD.org References: <199504280436.NAA00812@us.and.or.jp> In-Reply-To: <199504280436.NAA00812@us.and.or.jp>; from NIIMI Satoshi at Fri, 28 Apr 1995 13:36:14 +0900 Message-Id: Organization: Olahm Ha-Yetzirah Date: Fri, 28 Apr 1995 19:39:43 +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: 31 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1284 Sender: security-owner@FreeBSD.org Precedence: bulk In message <199504280436.NAA00812@us.and.or.jp> NIIMI Satoshi writes: >I've noticed with -current that when euid is not equal to ruid, >setuid(euid) fails but setreuid(euid, euid) successes. >But once setreuid(euid, -1) or setreuid(euid, euid), setuid(euid) >sccesses. >Please unify the rule for setre[ug]id() and set[ug]id(): >a) It is possible to change ruid if target is same as saved uid. >or >b) Only the superuser can change ruid. >IMHO: There is no need to give users the pass to change real user id. >The main aim of setre[ug]id() in 4.3BSD was to change e[ug]id. This >can be done by only sete[ug]id() in 4.4BSD. When we follow BSD 4.4 rule, we need to remove setre*() completely, because they cause very big confusion for all pgms which expects 4.2 way. Recently I call core team about removing them, but peoples prefer to implement them correctly (4.2 way) instead of removing. So, I do it. Now it is impossible to unify rule: it divides to POSIX and non-POSIX behaviour. -- 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 From owner-freebsd-security Fri Apr 28 20:26:55 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA05155 for security-outgoing; Fri, 28 Apr 1995 20:26:55 -0700 Received: from news.rim.or.jp (news.rim.or.jp [202.255.181.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA05149 for ; Fri, 28 Apr 1995 20:26:51 -0700 Received: (from uucp@localhost) by news.rim.or.jp (8.6.10+2.4W/3.3W-rim1.0) with UUCP id MAA16327; Sat, 29 Apr 1995 12:26:43 +0900 Received: from us.and.or.jp (localhost [127.0.0.1]) by us.and.or.jp (8.6.11/3.3W8) with ESMTP id LAA05883; Sat, 29 Apr 1995 11:30:44 +0900 Message-Id: <199504290230.LAA05883@us.and.or.jp> Reply-To: sa2c@st.rim.or.jp To: "Andrey A. Chernov, Black Mage" cc: security@FreeBSD.org Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc In-reply-to: "Andrey A. Chernov, Black Mage"'s message of Fri, 28 Apr 1995 19:39:43 +0400 Date: Sat, 29 Apr 1995 11:30:42 +0900 From: NIIMI Satoshi Sender: security-owner@FreeBSD.org Precedence: bulk > So, I do it. Now it is impossible to unify rule: it divides > to POSIX and non-POSIX behaviour. Hmm... I've tried to hack set[ug]id() to check saved id like setre[ug]id(). Does this hack violate POSIX standard? --- 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; -- NIIMI Satoshi 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 ; 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 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 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 From owner-freebsd-security Sat Apr 29 07:47:46 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA27179 for security-outgoing; Sat, 29 Apr 1995 07:47:46 -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 HAA27169 for ; Sat, 29 Apr 1995 07:47:40 -0700 Received: by sequent.kiae.su id AA27114 (5.65.kiae-2 ); Sat, 29 Apr 1995 18:44:41 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 29 Apr 95 18:44:41 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id SAA01695; Sat, 29 Apr 1995 18:40:12 +0400 To: Bruce Evans Cc: security@FreeBSD.org, "Garrett A. Wollman" References: <199504291339.XAA25148@godzilla.zeta.org.au> In-Reply-To: <199504291339.XAA25148@godzilla.zeta.org.au>; from Bruce Evans at Sat, 29 Apr 1995 23:39:09 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Sat, 29 Apr 1995 18:40:12 +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: 53 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2319 Sender: security-owner@FreeBSD.org Precedence: bulk In message <199504291339.XAA25148@godzilla.zeta.org.au> Bruce Evans writes: >>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. >I think the best possible is: >a) seteuid(euid) == setreuid(-1, euid) (deprecated like setreuid()) Dislike. seteuid() is introduced to help root to avoid setuid() POSIX restrictions. CSRG 4.4 have POSIX_SAVED_IDS root setuid() case (surprise). See seteuid comment into sys/sys/unistd.h >>1) seteuid() does not change svuid according to SunOS. >>From common sense it allows root to keep svuid untouched, >What does it do in Linux? I deleted my Linux sources, and the man >pages here are of a much lower quality than FreeBSD's :-). I can't found sete[ug]id() syscalls into Linux. It can be my fault or intentional thing, because POSIX_SAVED_IDS setuid() cover seteuid() case for non-roots. >>3) I don't see sec hole you point: > root: euid=0 ruid=0 svuid=any; exec setuid program to become > man: euid=9 ruid=0 svuid=0; setuid(9) to become > man: euid=9 ruid=0 svuid=0 >The setuid() is being done by an old program that isn't aware of POSIX >semantics. It expects to end up as ruid=9 but doesn't. Note that the >set[r]euid() semantics and the final value of svuid aren't important >here. Please, describe it more detaily: what started, which function called with what args exactly, etc. BTW, It is clear that POSIX setuid() works not the same way as non-POSIX :-) I.e. non-POSIX return -1 when POSIX can be successful. But as we claim ourselvs as POSIX-compatible, we must follow POSIX and converts pgms which conflict with it (as we already do with terminal driver f.e.). Lucky, looking through our sourses right now I don't find any pgms which conflicts. -- 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