Valentin Nechayev wrote: > 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?
I'll show you mine, if you show me yours. Can you prove that functional decomposition increases security? > Any MTA is big piece of little-structured code with unclear and mistransparent > logic, Only if it's written wrong. > full of errors, I'll agree that it takes a lot of effort to avoid errors. > and when a piece of code has only those privileges > which are survival for it, it provides additional barriers against exploiter. Exactly. It's a containment barrier, which treats the symtom of the disease, but does nothing against the disease. In fact, it _encourages_ people to do nothing about the disease, since the symptoms are treatable. A lot of pharmaceitical companies work this way, too: so long as they do not treat the disease, they have a nice captive market for their symtom-treating drugs. > There are too many examples now where such restrictions (non-root > execution, chroot,...) really kept against successful exploit. I'd like to see the raw data on this. > 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. Try replacing sendmail with qmail in FreeBSD 5.x. Try removing sendmail entirely, and maintaining lical mail service in FreeBSD 5.x. > > 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? No. Do you have any real examples of priviledge elevation from the status of "client of program" to the status of "system user $MAILUSER", subsequent to priviledge seperation in these programs? > If you have such arguments, please show them. Your argument is that I need to demonstrate priviledge elevation from "system user $MAILUSER" to that of "system user root". I think I can do this without difficulty, simply by demostrating the ability to write an executable file on the target system as "system user $MAILUSER", which could act as a trojan for "system user root". That's a minimal demonstration. Above and beyond that, I believe that it's possible to demonstrate on most systems a privilede escalation from "system user $ANY" to "system user root", and that the first line of defense is against remote exploit to escalate from "client of program" to the status of "system user whose ID is the same as that of the user running program". That is, in fact, the primary security model of OpenBSD. > I see only counterexamples: privilege separation restricts possible > attacks to a class which is rather more narrow than with monolithic design. It adds a hurdle between first and second base. I'll agree to that. But at the same time, it makes people less concerned about attackers getting to first base. And that's just wrong, philosophically: it's a false sense of security. Per OpenBSD, the first line of defense is the defense against getting to first base. > 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. This is incorrect. Sendmail before the functional decomposition did not have the problems which resulted in the subject of this thread: the problem arose following the seperation. In doing this seperation, my claim is that no real security was in fact gained (merely addition of an esclation hurdle: one more easily jumped than the hurdle of the initial escalation from client to user, per OpenBSD), and that this thread demonstrates that functionality was, in fact, lost. > 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 ;) I've already documented what needs to be done to run in a split horizon mode, both for DNS and for sendmail. > 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. This assumes a link up time less than the DNS retry timeout, given that the DNS requests are made via UDP datagrams, which are not reliably delivered. > 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. It's harder than it used to be, in 5.x, following the seperation, due to local mailer priviledge deescalation issues. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
