Maintain Security with sendmail - 4.2 The Environment
(Page 2 of 4 )
As a general rule, programs should never trust their environment. Such trust can lead to exploitation that has grave security consequences. To illustrate, consider the often misused SunOS LD_LIBRARY_PATH environment variable. Programs that use shared libraries look at this variable to determine which shared library routines they should use and in what order they should load them. One form of attack against non-set-user-id programs (such as some delivery agents) is to modify the LD_LIBRARY_PATH variable (as in a user’s ~/.forward file) to introduce Trojan horse library routines in place of the real system’s library routines. Certainly, sendmail should not pass such variables to its delivery agents.
To improve security, early versions of V8 sendmail began deleting variables from its environment before passing them to its delivery agents. It removed the IFS variable to protect Bourne shell-script agents and all variables beginning with “LD_” to protect all delivery agents from shared library attacks.
Beginning with V8.7, sendmail now takes the opposite approach. Instead of trying to second-guess attackers, it constructs the delivery agent environment from scratch. In this scheme, it defines the AGENT variable assendmail, and the TZ variable as is appropriate (see theTimeZoneSpecoption, §24.9.120 on page 1110). Also, in support of operating systems that require them, it passes the ISP and SYSTYPE variables from its own environment to the delivery agent’s environment.
4.2.1 The E Configuration Command When sendmail executes (runs) a delivery agent (§20.6.2 on page 757), it passes to that delivery agent an environment that includes only the items described earlier. Some delivery agents, however, might require additional environment variables to function properly. For those special cases, sendmail offers theEconfiguration command to set individual environment variables that will be passed to all delivery agents:
Evar=value
Thevar is the environment variable that will be either defined or redefined. It is immediately followed (with no intervening space) by an equal-sign and then (again with no intervening space) by thevalue that will be assigned to it.
If the=value is missing, sendmail looks up the variablevar in its environment and, if it is found, uses that value. If the=is present but thevalue is absent, thevar is assigned an empty string (a single zero byte). If thevar is missing, a variable name that is an empty string is used.
Thevar is looked up to see whether it is already a part of the delivery agent’s environment. If it is, it is redefined to be the new value. If it is not, it is added to that list of variables. If that addition will cause the list to exceed MAXUSERENVIRON variables (currently defined as 100 in conf.h, §3.4.22 on page 120), the definition is silently ignored.
Whether or not thevar was added to, or updated in, the delivery agent’s environment, it is always added or updated to sendmail’s environment with putenv(2). If this call fails, sendmail logs and prints the following message:
setuserenv: putenv(var=value) failed
Only onevar can be defined perEcommand. Additional environment variables require multipleE commands. EachEcommand affects all delivery agents. There is no way to tune the environment on a per-delivery-agent basis.
Next: 4.3 SMTP Probes >>
More Server Administration Articles
More By O'Reilly Media
|
 This article is excerpted from chapter four of sendmail, fourth edition, written by Bryan Costales, Claus Assmann, George Jansen and Gregory Shapiro (O'Reilly, 2007; ISBN: 0596510292). Check it out today at your favorite bookstore. Buy this book now.
|
|
