From owner-freebsd-security Sun Nov 17 19:02:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA03783 for security-outgoing; Sun, 17 Nov 1996 19:02:57 -0800 (PST) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA03774 for ; Sun, 17 Nov 1996 19:02:47 -0800 (PST) Received: (adam@localhost) by homeport.org (8.6.9/8.6.9) id VAA10674; Sun, 17 Nov 1996 21:59:29 -0500 From: Adam Shostack Message-Id: <199611180259.VAA10674@homeport.org> Subject: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2). In-Reply-To: from Warner Losh at "Nov 17, 96 07:55:10 pm" To: imp@village.org (Warner Losh) Date: Sun, 17 Nov 1996 21:59:29 -0500 (EST) Cc: freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: | In message <9611180247.AA15359@communica.com.au> Mark Newton writes: | : sendmail really only needs root so that it can bind to the "privileged" | : port 25 when it's running in daemon mode. If you frob filesystem permissions | : sufficiently you can get away without providing sendmail with root | : privileges by running it with a non-root uid out of inetd (which is, | : indeed, precisely what I have done with it here at Communica, where | : sendmail runs as the unprivileged "smtp" user). | | I don't buy this. You need to be able to create a mailbox of an | arbitrary user, and then write to that mailbox with that user's uid, | or to a shell of that user's uid. To do otherwise would introduce | other security problems, some of which have been beat to death in the | freebsd lists. Sendmail doesn't need to create/write to mailboxes, mail.local*, needs to do that. The problem with sendmail is that its a desert topping and a floor wax. It wants to do everything, and you can't do everything and be secure. Theres no solid seperation of privledge (as enforced by qmail's multiple programs under different uids). Theres no least privledge, as seen with qmail's one of 14 programs being setuid. The need for a setuid program to deliver mail does not mean that the mail parser, the MX handler, the envelope mangler, and the router core need to be setuid. *procmail, qmail-lspawn can substitute for mail.local. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume