<CHAPTER ID="ZADM-SECURITY"><?dbhtml filename="zadm-security.html">
<TITLE>Security Issues</TITLE>

<PARA>
Having local-parts that allow delivery to arbitrary files, or which can
trigger execution of arbitrary programs, can clearly lead to a huge security
problem.
<COMMAND>sendmail</> does address this problem, but in a restrictive and
unintuitive manner.  This aspect of ZMailer security has been designed to
allow the privileges expected by common sense.
</PARA>

<PARA>
The responsibility for implementing this kind of security is split between
the <COMMAND>router</> and the <EMPHASIS>transport agent</> that delivers
a message to an address.
Since it is the Transport Agent that must enforce the security, it needs
some information to guide it.  Specifically, for each address it delivers
to, some information about the ``<EMPHASIS>trustworthiness</>'' of that
address is necessary so that the transport agent can determine which
privileges it can assume when delivering for that destination.
This information is determined by the <COMMAND>router</>, and passed
to the transport agent in the message control file.
The specific measure of trustworthiness chosen by ZMailer, is simply
a numeric user id (uid) value <EMPHASIS>representing the source of
the address.</>
</PARA>

<PARA>
When a message comes into the mailer from an external source,
the destination addresses should obviously have no privileges
on the local host (when mailing to a file or a program).
Similarly, common sense would indicate that locally originated mail
should have the same privileges as the originator.
Based on an initial user id assigned from such considerations, the privilege
attached to each address is modified by the attributes of the various alias
files that contain expansions of it.
The algorithm to determine the appropriate privilege is to use the user id
of the owner of the alias file if and only if that file is not group or world
writable, and the directory containing the file is owned by the same user
and is likewise neither group nor world writable.
If any of these conditions do not hold, an unprivileged user id will
be assigned as the privilege level of the address.
</PARA>

<PARA>
It is entirely up to the transport agent whether it will honour the
privilege assignment of an address, and indeed in many cases it might not
make sense (for example for outbound mail).  However, it is strongly
recommended that appropriate measures are taken when a transport agent has
no control over some action that may affect local files, security, or
resources.
</PARA>

<PARA>
The described algorithm is far from perfect. The obvious dangers are:
<ITEMIZEDLIST>
<LISTITEM><PARA>
 The grandparent directories, to the Nth degree, are ignored, and may
not be secure. In that case all security is lost.
</PARA></LISTITEM>
<LISTITEM><PARA>
There is a window of vulnerability between when the permissions are
checked, and the delivery is actually made.
This is the best argument for embedding the entire local-aliasing
into the local-delivery agent program.
</PARA></LISTITEM>
</ITEMIZEDLIST>
</PARA>


<PARA>
There is also another kind of security that must be addressed.
That is the mechanism by which the <COMMAND>router</> is told
about the origin of a message.
This is something that must be possible for the message receiving
programs (<COMMAND>/bin/rmail</> and the <EMPHASIS>SMTP server</>
are examples of these) to specify to ZMailer.
The <COMMAND>router</> knows of a list of trusted accounts on the system.
If a message file is owned by one of these user id's, any sender specification
within the message file will be believed by ZMailer.
If the message file is not owned by such a trusted account, the
<COMMAND>router</> will cross-check the message file owner with any
stated <QUOTE><LINK LINKEND="rfc822.from">From:</></> or
<QUOTE><LINK LINKEND="rfc822.sender">Sender:</></> address 
in the message header, or any origin specified in the envelope.
If a discrepancy is discovered, appropriate action will be taken.
This means that there is no way to forge the internal origin of
a message without access to a trusted account.
</PARA>

<PARA>
Trusted accounts are those listed in the ZMailer group or the ``trusted'' 
variable in the system configuration (<FILENAME>router.cf</>) file.
</PARA>

<PARA>
Of course when one uses SMTP protocol to inject email, it is extremely
easy to ``fake'' any source and destination envelope and visible addresses.
</PARA>

<PARA>
The intention of the security mechanisms is not to prevent address faking,
but to control the privileges which are used to execute pipes, and
accessing files (read, and write).
</PARA>

</CHAPTER>
