Bug#47709: Some scripts way, way out of date
On Sun, 24 Oct 1999, Raul Miller wrote:
> We're picking nits, so I expect that this will be my last message to
> the bug tracking system on this topic.
OK. I think it would be wise to keep focused on the fact that most people
are going to be installing the "cgi-scripts" package entirely for tutorial
purposes, meaning that they want to learn how to write CGI scripts. As a
result, these scripts should make an effort to capture a consensus of best
practices in terms of flexibility, security, and portability.
> > If we assume that the particular thing invoked by running a
> > program called "sendmail" from CGI is, in fact, the thing that is
> > conventionally known as "Sendmail" and which is contained in the
> > Debian package of that name, rather than a symbolic link to something
> > else, then I think it is clear that the end result is going to be
> > authentication warning messages in the headers of outgoing mail. There
> > are only two "local administrative" ways to avoid this: (1) run the
> > CGI program suid as a "trusted" user, which is insane, or (2) add the
> > web server owner uid ("www-data" for Debain, "nobody" by default) as a
> > trusted user, which is only a bit less insane.
>
> (3) install something other than the "sendmail" package.
>
> And I disagree with your concept of insane. Any system which trusts smtp
> connections but does not trust local users in the same fashion is insane.
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.
> > 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.
> > Using the Net::SMTP approach, there is complete freedom to set
> > different addresses for the sender evelope, the "From" header, the
> > "Reply-To" header, and so on, and there are no security implications
> > (such as whether the sender is "trusted") to worry about.
>
> 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.
> > Accepting your argument that running an SMTP listener on the web
> > server is a bad idea from a security point of view, what then
> > is the best solution? What you are proposing is that someone
> > would have to install Sendmail, configure it, and then manually
> > modify the Debian-provided shell script which starts Sendmail
> > ("/etc/init.d/sendmail") so that it could be run as a queue processing
> > daemon but not an SMTP listening daemon. This implicates, I think,
> > a Debian policy issue: it might be reasonable (although, I contend,
> > unnecessary) for the "cgi-scripts" package to suggest the "sendmail"
> > package, but certainly not to require hand-editing the daemon start-up
> > shell script to implement a configuration that is so rarely used with
> > Sendmail that the standard switches are hardcoded. It is important to
> > remember that Sendmail will never take the mail out of the queue if it
> > is not running as some sort of daemon.
>
> I agree that this is a debian policy issue. I've already raised this
> issue in another context, and there's already been some discussion of
> it. There's currently a rough consensus that, once the deb config
> system (which provides more advanced support for options which are
> currently .postinst prompts), it should be possible for the sysadmin
> to control whether packages automatically start network listeners. Once
> that's done I think that it will be reasonable to ask that this issue
> be dealt with in the sendmail package.
>
> Until then, I'll stand by my philosophy that sendmail is not worth
> installing in most circumstances.
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.
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.
> > If someone regards Sendmail as a security risk on the web server, and I
> > agree that this might be an entirely reasonable view, then it is more
> > likely that they would either install no mail system at all, in which case
> > there would be nothing on the machine for you to invoke directly, or they
> > would install one of the "higher security" modular systems such as smtpd,
> > in which case your direct invocation method would not work. Worse, if
> > someone chose to run one of these higher security or alternative mail
> > systems, and the "cgi-scripts" package suggested "sendmail," then this
> > would cascade through the package-dependency tables because the "sendmail"
> > package quite properly states "Conflicts: mail-transport-agent, smail."
>
> 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 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.
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.
-- Mike
Reply to: