Security Issues

ZMailer: The Manual; v1.99.20
Prev |  | Next

# Chapter 10. Security Issues

Having local-parts that allow delivery to arbitary files, or which can trigger execution of arbitrary programs, can clearly lead to a huge security problem. 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.

The responsibility for implementing this kind of security is split between the router and the 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 ``trustworthyness'' 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 router, and passed to the transport agent in the message control file. The specific measure of trustworthyness chosen by ZMailer, is simply a numeric user id (uid) value representing the source of the address.

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.

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.

The described algorithm is far from perfect. The obvious dangers are:

- The grandparent directories, to the Nth degree, are ignored, and may not be secure. In that case all security is lost.

- There is a window of vulnerability between when the permissions are checked, and the delivery is actually made. This is the best argument I have heard so far for embedding the local delivery program (currently a separate transport agent) in the router.

There is also another kind of security that must be addressed. That is the mechanism by which the router is told about the origin of a message. This is something that must be possible for the message receiving programs (/bin/rmail and the SMTP server are examples of these) to specify to ZMailer. The 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 router will cross-check the message file owner with any stated "From:" or "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 origin of a message without access to a trusted account.

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

Prev | Home | Next
DNS and ZMailer | Up | The Queue