From owner-freebsd-security Fri Jan 10 01:19:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA01815 for security-outgoing; Fri, 10 Jan 1997 01:19:28 -0800 (PST) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA01810 for ; Fri, 10 Jan 1997 01:19:24 -0800 (PST) Received: from sidhe.hsc.fr (pb@sidhe.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.4/8.8.4/itesec-1.9) with ESMTP id KAA21384; Fri, 10 Jan 1997 10:19:20 +0100 (MET) Received: (from pb@localhost) by sidhe.hsc.fr (8.8.Alpha.4/sidhe-new-1.7) id KAA08316; Fri, 10 Jan 1997 10:19:19 +0100 (MET) Message-ID: Date: Fri, 10 Jan 1997 10:19:18 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: roberto@keltia.freenix.fr (Ollivier Robert) Cc: freebsd-security@freebsd.org Subject: Re: sendmail running non-root SUCCESS! References: <199701091347.IAA23487@homeport.org> X-Mailer: Mutt 0.50 Mime-Version: 1.0 In-Reply-To: ; from Ollivier Robert on Jan 9, 1997 20:04:12 +0100 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Ollivier Robert: > According to Pierre Beyssac: > > Not exactly (though I don't know procmail well enough: maybe it > > can do that too). > > Look on your own machine Pierre, that's the way I set it up when it was > mine :-) The way to do it is to use FEATURE(local_procmail). Maybe I was unclear, but I was not considering the 'local' mailer, since as far as I know it doesn't require sendmail to be setuid. I was talking about the 'prog' mailer and as far as I know and unless I missed something, procmail can't handle that. > > 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. > > It is very easy to implement (winthin sendmail). Now, where is the patch > for the run-as-user program ? :-) Patch? It would take a little more than a patch, I'm affraid ;-)! The run-as-user program would have to be setuid, with some kind of access checking more complicated than just checking that sendmail is calling it (or we're almost back to square one with sendmail holes). > > I don't know how easy it would be to make this secure, it's just an > > idea. My feeling is that it should be possible to define something > > more modular than sendmail, with only very few parts setuid inside. > > That's Qmail for you. Uh, okay, when Qmail will be configuration-compatible with sendmail, we can talk about it. In the meanwhile, why not try to fix sendmail by improving its implementation somewhat? There certainly are other options than dropping sendmail alltogether on the premise that it's broken. If it's broken, it should be fixed. -- Pierre.Beyssac@hsc.fr