From owner-freebsd-security Wed Nov 18 09:43:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07091 for freebsd-security-outgoing; Wed, 18 Nov 1998 09:43:59 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07084 for ; Wed, 18 Nov 1998 09:43:54 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id JAA22891; Wed, 18 Nov 1998 09:39:57 -0800 (PST) (envelope-from marcs@znep.com) Date: Wed, 18 Nov 1998 09:39:56 -0800 (PST) From: Marc Slemko To: Garance A Drosihn cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Nov 1998, Garance A Drosihn wrote: > At 2:14 PM -0600 11/17/98, William McVey wrote: > >Cliff Skolnick wrote: > >> I am more concerned about stand alone daemons like sendmail, > >> syslog, apache, etc. > > > > Most of these services could easily be modified to start from > > inetd as wait services. Basically, inetd does the port binding, > > setuid-ing, and execing, just like it always does. As I've > > mentioned before, sendmail can definitely run in this manner. > > So could most web servers. > > Seems to me the performance implications for web serving is > not very attractive. In my case I just go with a minimalist > web server (not apache, I think the name is just "thtppd") > to reduce the security exposure. (well, it reduces the > feature set too, of course, but I don't need the missing > features). You may think that going with a minimalist so-called secure program gives you an advantage, but that isn't necessarily the case. With thttpd, for example, when I took a look at it a few months ago it didn't take more than a few minutes to figure out how it can be used to read any file on the system that the user running it has access to. That is now fixed in the current version, but if five minutes found that, who knows what actually sitting down and seriously trying to find holes would do. It is also possible for any user that can write content to block the entire server from working for anyone. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message