Date: Thu, 2 Jan 2003 10:59:21 +0200 From: Valentin Nechayev <netch@iv.nn.kiev.ua> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-current@FreeBSD.ORG Subject: [OT] sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay) Message-ID: <c9622346-1e23-11d7-83f4-0002b32ee8e9@iv.nn.kiev.ua> In-Reply-To: <3E13D095.FC52B758@mindspring.com> References: <rgptrg1uzx.trg@localhost.localdomain> <3E1352BC.4043921B@mindspring.com> <20030101145232.A391@zardoc.esmtp.org> <3E13D095.FC52B758@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wed, Jan 01, 2003 at 21:39:33, tlambert2 (Terry Lambert) wrote about "Re: 5.0-RC2 informal PR: 90 sec sendmail delay": TL> It's an editorial complaint. I don't like the breaking the TL> program into seperate programs by function. IMO, DJB is wrong, TL> and this does nothing to enhance security. Can you please prove this conclusion, or at least show real arguments? Any MTA is big piece of little-structured code with unclear and mistransparent logic, full of errors, and when a piece of code has only those privileges which are survival for it, it provides additional barriers against exploiter. There are too many examples now where such restrictions (non-root execution, chroot,...) really kept against successful exploit. And DJB wasn't first, AFAIK; first was zmailer with its authors. (Please fix if I'm wrong.) TL> The result of doing TL> this in FreeBSD has been to greatly complicate rc scripts, with TL> the result that sendmail is much less of an unpluggable component TL> that can be replaced with something else, easily, and with little TL> system impact. Even in FreeBSD4 with its semi-monolithic /etc/rc, sendmail is easily startable from its own script. TL> I understand the "security" reasoning, based on having to compete TL> with qmail and other packages that claim this seperation magically TL> fixes all security issues. But it's just a propaganda move, and TL> it's not technically justified. It is technically justified. Do you have real arguments that any attack that can be performed with monolithic program run from root, is also successful with program with privilege separation? If you have such arguments, please show them. I see only counterexamples: privilege separation restricts possible attacks to a class which is rather more narrow than with monolithic design. TL> Similarly, the interior seperation, which is what resulted in the TL> DNS lookup that brought up the link in this current discussion TL> thread, fails via a timeout before the lookup is done, and so the TL> transfer fails. This has nothing common with privilege separation. Design of sendmail is too hard bound with concept of node constantly linked with Internet. To make it happy without full DNS accessible, you should perform some actions which are documented but their description hides in tons of ore. Standard FreeBSD configs hasn't got these options. You can send fix ;) TL> time that the timeout would fire, and the mail would never end up TL> getting sent (it would get aged into the queue as "can't lookup TL> destination host"). I fix it with: define(`confDIRECT_SUBMISSION_MODIFIERS',`CC u')dnl For now I has no such problem at my home machine. Yes, this solution isn't intuitive. TL> And one result is a FreeBSD where it's harder to pull sendmail out TL> and replace it (also a marketing win, from a sendmail perspective). TL> Personally, I use sendmail, so yanking it out is not high on my list TL> of things to do, but it's now harder to have base mail functionality TL> without parts of sendmail sticking around. I use sendmail, also. Possibly, due to old habit. But I'm waiting for moment when I can erase this crap from my hosts. -netch- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c9622346-1e23-11d7-83f4-0002b32ee8e9>