From owner-freebsd-security Mon Nov 16 11:42:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28019 for freebsd-security-outgoing; Mon, 16 Nov 1998 11:42:30 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27997 for ; Mon, 16 Nov 1998 11:42:18 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA13971; Mon, 16 Nov 1998 12:40:14 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA19331; Mon, 16 Nov 1998 12:40:12 -0700 Date: Mon, 16 Nov 1998 12:40:12 -0700 Message-Id: <199811161940.MAA19331@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: Andre Albsmeier , Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811161849.LAA05146@harmony.village.org> References: <19981116125909.A28486@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <199811152210.PAA01604@harmony.village.org> <199811160658.XAA01912 < Your message of "Mon, 16 Nov 1998 12:59:09 +0100." <19981116125909.A28486@internal> <199811161849.LAA05146@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > : That is exactly my opinion. I think a program should run with the > : minimum privileges it really needs to and not more. > > I still think that it is a lot of effort for just one or two > programs. xlock and xlockmore (basically the same program) are the > only two programs that I'm aware of that need to access the password > file and not change the uid of the process. Where are the rest of the > half dozen :-)... The other issue is since they will no longer be setuid(), someone can crash them and get the passwd file from them to crack later or we'd have to change all of the 'don't dump core' code to look for setgid(passwd) stuff. All of a sudden this 'simple fix' gets to be obnoxious and isn't buying us a whole lot. Setuid is *NOT* evil in all cases, you simply must be careful. The fact of the matter is *some* programs must have root priviledges to do their job securely and/or at all. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message