|
Chapter 22 Security |
|
22.2 The Environment
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- suid 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, 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 instead constructs
the delivery agent environment from scratch. In this scheme it
defines the AGENT variable as
sendmail
, and the TZ
variable is as appropriate
(see the
TimeZoneSpec
(
t
) option,
Section 34.8.69, TimeZoneSpec (t)
).
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.
22.2.1 The E Configuration Command
When
sendmail
executes (runs) a delivery agent (see
Section 30.6.2, "The Child"
),
it passes to that delivery agent an environment that includes only the
items described above.
Some delivery agents, however, may require additional environmental variables
to function properly. For those special cases,
sendmail
offers the
E
configuration command to set individual environment variables
that will be passed to all delivery agents:
Evar=value
The
var
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 the
value
that will
be assigned to it.
If the
=
value
is missing,
sendmail
looks up the variable
var
in its environment and, if it is found, uses that value. If the
=
is present
but the
value
is absent, the
var
is assigned an empty
string (a single zero byte). If the
var
is missing,
a variable name that is an empty string is used.
The
var
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 (as defined in
conf.h
, see
Section 18.8.19, MAX...
),
the definition is silently ignored.
Whether or not the
var
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 one
var
may be defined per
E
command. Additional environment
variables require multiple
E
commands.
Each
E
command affects all delivery agents. There is no way to tune the
environment on a per delivery agent basis.
For DG/UX under V8.7 sendmail you will need to declare
E_FORCE_MAIL_LOCAL_=yes
in your configuration file to enable /bin/mail to work properly. Beginning with V8.8 sendmail , this is already done in cf/ostype/dgux.m4 .
|
|
|
|
| 22.1 Why root? |
|
22.3 SMTP Probes |