Date: Thu, 02 Jan 2003 21:05:18 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Claus Assmann <freebsd+current@esmtp.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: 5.0-RC2 informal PR: 90 sec sendmail delay Message-ID: <3E151A0E.E7D61933@mindspring.com> References: <rgptrg1uzx.trg@localhost.localdomain> <3E1352BC.4043921B@mindspring.com> <20030101145232.A391@zardoc.esmtp.org> <3E13D095.FC52B758@mindspring.com> <20030102104810.A27967@zardoc.esmtp.org> <3E14ACAC.2014C867@mindspring.com> <20030102193059.A30727@zardoc.esmtp.org> <3E150B9F.3F29FB8E@mindspring.com> <20030102202128.A8458@zardoc.esmtp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Claus Assmann wrote: > > If it's a bug that needs to be fixed, it's a bug in the host OS, > > and not something that sendmail can address. > > So your claim is wrong. You can't use the mailuser account to raise > your priviledges to root. What did you want me to do, enumerate all possible methods of escalating priviledge from a non-root user to root, after using a theoretical future vulnerability to get a shell as a non-root user instead of root? > Ok, let me say it once: this is B.S. This is not a P.R. problem, > it is a real technical problem as I proved to you before. Any problem which you have to answer for, but which is not a problem with your software is, by definition, I think, a PR problem. FreeBSD itself is no stranger to this; FreeBSD is mentioned in CERT advisories (unfairly) for software from third-party vendors, which are bugs in the third-party software, not bugs in the FreeBSD OS, itself. It's perfectly valid to make some technical changes for business reasons; FreeBSD did this, too, when inetd was disabled by default, even when there were no known exploits for the fact it was running as root: no technical reason for the change, except the inability of a competitor to claim better security than FreeBSD because they had disabled inetd, and FreeBSD had not, and the common perception that running a program that accepted network connections as root was "risky". Heck, OpenSSH modified their architecture and *added* a remote root exploit (later closed) in the process of supposedly addressing priviledge, for the same business reasons. > Since this discussion is off-topic for this list and you are not > able to prove your point, I stop here. > > If you want to continue, I invite you to read the sendmail 9 design > document and to tell me which of the parts that involve the security > features of it are flawed. > > http://www.sendmail.org/~ca/email/sm-9-rfh.html This URL gives a page where you can send email to you to request the document, after signing an NDA, which you have to request first. I'm willing to at least look at, and decide whether I want to sign, the NDA, so if you are willing, please send it to me: I am interested in looking at sendmail functionally for large installations and heavy mail volume, as well as from a security standpoint (per the current discussion). Thanks, -- Terry 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?3E151A0E.E7D61933>