Date: Sun, 24 Nov 1996 13:44:51 +1030 (CST) From: newton@communica.com.au (Mark Newton) To: marcs@znep.com (Marc Slemko) Cc: imp@village.org, newton@communica.com.au, freebsd-hackers@freebsd.org Subject: Re: non-root users binding to ports < 1024 (was: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).) Message-ID: <9611240314.AA03473@communica.com.au> In-Reply-To: <Pine.BSF.3.95.961123150746.5433B-100000@alive.ampr.ab.ca> from "Marc Slemko" at Nov 23, 96 03:33:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Slemko wrote: > > : This thread started in freebsd-security earlier in the week; it > > : evolved from a discussion of the reasons why sendmail runs as root. > > > > The other reason that sendmail needs to run as root is to fork of user > > shells on mail delivery. Has there been any thought as to how to > > solve that problem? It was ignored while this thread was going on in > > -security, and should not be ignored. I tried to make this point, but > > no body was listening to me there, or so it appeared. This is an > > absolute requirement for a mail system based on sendmail. > > That's one of the reasons I am not sure about the usefulness for sendmail > of letting non-root users bind to ports below 1024. One choice is to > simply not let users run local delivery agents. Not an acceptable general > solution, but perfectly acceptable local policy for _some_ systems. The mechanisms that have been suggested are envisaged precisely to permit _some_ systems to make local policy decisions about how to handle sendmail. The mechanisms are enabling; they do not affect present users. > The other choice is to have some external (and small) delivery program > that handles it; with the local delivery program running as root. We already have one, it's called mail.local. As I tried to say to Warner, the whole idea of shoving shell execution into the MTA is bogus. Not only does it blow the model of having seperate delivery agents out of the water, it also leads to arguments like Warner's, where continuing to run a demonstrably unsecure program with special privilages is mandated to continue simply because the alternative would break someone's pet feature. > For > example, you could have a seperate program that is setuid root which > handles the final delivery stage if a program needs to be run. You need > to be very careful that nothing which is passed to it can make it do > undesirable things because when the user sendmail is running as is > compromised then the person can pass anything they want to the "program > execution agent" to try to make it do bad things. Which is precisely why sendmail shouldn't be doing shell execution: History has shown (and will, in all likelihood, continue to show) that sendmail is woefully inadequate at checking data passed to it by users. I am not aware of any sendmail security bugs which have been caused by major architectural flaws, but in every case security bugs have been solved by fixing up sendmail's sloppy implementation. Given that sendmail has shown such a history of sloppiness, I'm simply amazed that we continue to trust it with the front door keys to our systems. Sendmail does not need root. Sendmail should not have root. Thus far, the only argument I've seen to suggest that sendmail should have root is, "We've always done it that way." There is currently no standard facility to make it do it any other way, either. Permitting a selected subset of non-root processes to bind to ports < 1024 is, IMHO, the first step to such a stadnard. > > While I think it is maybe useful to allow binding to port 1024 to > > non-root programs, it is also potentially dangerous and should only be > > entered into if you are sure that there are *NO* holes possible. This makes me laugh. Warner apparently favours the alternative, which is that we're essentially certain that sendmail is full of holes, and we'll knowingly continue to give it root to satisfiy the needs of a misfeature (to whit: shell escapes). - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9611240314.AA03473>