Bug#47709: Some scripts way, way out of date
Argh... I hoped I was done.
On Mon, Oct 25, 1999 at 05:10:21AM -0400, Mike Bilow wrote:
> My point is that running things from the console generally involves
> issues of trust, ownership, and the like. A "trusted user" has
> a particuar technical meaning for Sendmail. By contrast, SMTP
> connections are assumed to be publicly accessible, and therefore have
> all sorts of protections on them by default. In the case of Sendmail,
> the address formats may be validated through the "check_mail" ruleset,
> promiscuous relaying may be disabled for non-local senders through the
> "check_rcpt" ruleset, and so on. In general, forcing communication
> to go through a narrow public interface such as SMTP should improve
> security.
You're talking about a flaw in sendmail.
For local delivery, the check_mail ruleset matters. For remote delivery
it's completely irrelevant.
Using a different mail transport agent (in this case you're recommending
perl's Net::SMTP) is as far as I know the only way around the problem, but
that issue is a *sendmail* bug, not a *cgi-examples* issue.
> > > In your example syntax, because you are not using the "-f" switch, you
> > > will not generate an "authentication warning." However, the sender
> > > envelope address, to which bounces and delivery notification failures will
> > > be sent, would be left as the process owner for the web server, such as
> > > "www-data" or "nobody." Assuming that a mail alias has been properly
> > > configured for this, it is almost certainly going to be the mailbox of the
> > > person responsible for the web server as a whole. Especially on a web
> > > server which has a lot of different virtual sites and many page authors,
> > > this is probably extremely undesirable, and such a recipient may not even
> > > be able to track down which CGI maintainer is responsible.
> >
> > This depends on the web server itself.
> >
> > Using the default configuration under apache, that's true. However, if
> > you have many authors of cgi pages you should be using a web server which
> > is configured to run cgi's under the userid of the web page author.
> >
> > If you have only a small number of web page authors it's reasonable to
> > install a .forward file to redirect such bounces to someone appropriate.
>
> I vehemently disagree that it is desirable or even supported to run CGI
> processes suid, and certainly not suid as real users. Very grave security
> holes can be introduced by doing this, and the Debian Apache configuration
> declines to run CGI processes which are flagged suid. It is possible to
> invoke CGI programs indirectly and deliberately circumvent these
> protections, but this should only be done where absolutely necessary and
> an assessment of the risks has been made, and then still should use
> mechanisms such as "chroot" if possible. Under no circumstances would
> something like this bejustified simply to set a mail bounce address, and I
> would object to it being portrayed as good practice in the "cgi-scripts"
> package which has principally tutorial value.
Where did I suggest SUID executables?
I suggested configuring the web server so that it runs the process under
a user id of the author under certain circumstances.
Certainly, having one web server per author, and chrooting that web
server, is a viable way to do this.
On the other hand, if you have a small number of authors -- and
especially if they're working together -- I would not recommend this
approach.
> > Once again, the whole concept of trusting port 25 but not trusting
> > local users (who can connect to port 25) is completely bogus.
>
> My view is that port 25 is equally untrusted for everyone.
Sure, but you're concerned about sendmail's implementation where
to supress authentication warnings on mail going to an untrusted
port 25 you have to tell sendmail to trust the user locally.
> It would actually be fairly easy for the maintainer of the "sendmail"
> package to make this sort of thing configurable, or at least editable in
> "/etc/init.d/sendmail" in the same way that the queue interval is now.
> However, there is almost no demand for installing Sendmail so that it runs
> the queue as a daemon but does not listen on the SMTP port, and there has
> to be some realistic acceptance that the package maintainer cannot be
> expected to provide for every possible exotic implementation of anything
> as complicated as Sendmail. I suppose that the package maintainer should
> probably be willing to support anything which is both easy to do and for
> which there is some demand, but I doubt anyone has ever even suggested
> putting this capability into the "sendmail" package until now.
There is actually quite a lot of demand for a variety of mail
configurations which are not easy under sendmail, but sendmail is
so intimidating that people usually switch to other mechanisms for
deliverying mail rather than bother the sendmail author with them.
Consider, for example, how many years went by with sendmail being a
security hole before that got addressed.
> I consider myself fairly experienced with Sendmail, but I cannot recall a
> single instance in which I found it appropriate to install Sendmail to run
> as a daemon for queue processing but not SMTP listening, even on UUCP
> systems. The closest I can recall coming to such a configuration was on a
> mail server whose only connection to the outside world was via UUCP with
> dial-on-demand, but even then people on its local Ethernet LAN submitted
> messages into the system using SMTP. That particular installation was
> probably over 10 years ago, as it was a Xenix system and I remember
> personally ripping out mmdf and installing Sendmail. In other words,
> asking the "sendmail" package maintainer for this should be an extremely
> low priority request.
I don't know why you're talking about not being aware of a case where
this would be useful when I just gave you one: you're managing a farm
of web servers, you don't want them to be exposed to the net on port
25 but you want to send mail for administrative purposes.
Ok, I probably wouldn't bother with Sendmail for this instance, because
it has other flaws. But sendmail flaws should not be used as a reason
to deny that sendmail has other flaws.
> > I think it would be reasonable for cgi-scripts to suggest
> > mail-transport-agent
> >
> > I think it's reasonable to file bugs against any package which provides
> > mail-transport-agent which does not support /usr/lib/sendmail -oem -oi -t
> > [though I'm not aware of any such package].
>
> I think it would be more appropriate to write the example CGI scripts to
> use the provided interface that Perl supplies for sending mail, which is
> Net::SMTP. (Other Perl interfaces, such as Mail::Mailer, actually do
> depend upon an external mail transport agent.) If you use Net::SMTP to
> point to "localhost," then you get pretty much all of the benefits of
> invoking a fully-installed Sendmail directly, including queueing. And, if
> there is no mail system on the machine, you can point at something else.
I disagree with this attitide: that if perl has an interface that you
must use it merely because perl supplies it.
If you're familiar with more than one interface, you should pick one
whose semantics best match your problem domain, and whose interface
is appropriate to your needs.
Given perl's philosophy ("There's more than one way to do it"), I think
it's appropriate to provide a variety of examples of different ways to
accomplish the same end.
> I think that there would be little sympathy in the Debian
> community for treating as a bug the failure of an alternative
> "mail-transport-agent" to support the precise command line syntax of
> Sendmail. In such cases, the problem would really only be resolvable
> by the upstream author, and there is little to be gained by forwarding
> something like this upstream. Especially where, as in your example,
> the "-o" switches are involved, the command line syntax of Sendmail is
> something of a moving target.
Believe me, I'm aware of the flaws in sendmail. However, there are a
number of mail user agents which rely on this exact syntax from sendmail,
and the mail-transport-agent virtual package exists exactly to support
these mail user agents. [Note that there's even a debian package
"ssmtp" where mail-transport-agent provides /usr/lib/sendmail but no
port 25 listener.]
> Whether the "cgi-scripts" package should suggest "mail-transport-agent"
> seems potentially controversial to me. As we agreed, there are security
> risks associated with running mail on the same system as a web server. It
> is very common to do it, but I am not sure that Debain should "suggest" it
> as an example of good practice. Rather, it is more in the nature of an
> economic compromise.
OK, it doesn't need to Suggest: mail-transport-agent. And it's true that
it's up to the author of that package to pick what examples are presented.
However, to classify the potential solutions:
Most secure:
no smtp listener
mail smarthost as network neighbor
Least secure:
smtp listener
ill-configured Sendmail as local mail transport agent
Fastest:
queue mail for later delivery
Slowest:
implement mail transport agent in CGI
Most error feedback:
implement mail transport agent in CGI
Least error feedback:
queue mail for later delivery
Most convenient:
[the implementation with the highest content/statement ratio --
that is, the one with the least number of keystrokes to represent
the required statements].
Best:
pick one -- it depends on what you're trying to achieve
--
Raul
Reply to: