From owner-freebsd-security Thu Jan 9 18:02:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA06246 for security-outgoing; Thu, 9 Jan 1997 18:02:37 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA06237 for ; Thu, 9 Jan 1997 18:02:33 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id SAA28004 for ; Thu, 9 Jan 1997 18:03:12 -0800 (PST) Received: (qmail 27034 invoked by uid 110); 10 Jan 1997 02:01:53 -0000 Message-ID: <19970110020153.27033.qmail@suburbia.net> Subject: Re: sendmail running non-root SUCCESS! In-Reply-To: from Pierre Beyssac at "Jan 9, 97 03:35:12 pm" To: Pierre.Beyssac@hsc.fr (Pierre Beyssac) Date: Fri, 10 Jan 1997 13:01:53 +1100 (EST) Cc: adam@homeport.org, Pierre.Beyssac@hsc.fr, giles@nemeton.com.au, lyndon@esys.ca, moke@fools.ecpnet.com, freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (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 > sendmail could process the .forward as usual, but it would > call the external prog mailer to ask it to run "/home/user/bin/myownstuff" > as "user" and pipe the mail to it. > > Obviously it has to be more complicated than that or it would > be a trivial new hole in the system (we can't rely on just checking > that sendmail is calling us, that would not make us immune to attacks > on sendmail itself). > > A solution might be to use a .db database as someone suggested, > as an authenticated reference owned by root or mail, accessed > by sendmail and the prog mailer. > > -- > Pierre.Beyssac@hsc.fr > Bork. Instead of spending hours whipping and splinting a dying nag into going an extra furlong, why not just put a little more shine on the young filly called 'qmail'? I'm serious. If qmail doesn't handle what you want (optimal-uucp-handling) then extend it. Because of qmail's well-thought-out modularity and multiple division of powers, this task is not hard and has virtually zero chance of introducing security holes. Cheers, Julian.