In the first week after its public release, people have subjected the Postfix software to a high level of scrutiny. I will respond to the claims that have been made sofar. In my opinion, no-one has brought forward a vulnerability worth mentioning. First I'd like to emphasize that the primary objective of Postfix was to protect the local system. With today's protocols that lack any form of strong authentication, I make no promise that Postfix can be made immune against DNS spoofing, IP address spoofing, or SMTP sender address spoofing. Secondly, all topics of controversy are the result of deliberate design decisions, not accidental properties of the implementation. I suppose that one man's bug is another man's feature. The remainder of this message addresses specific claims. Wietse By default, Postfix relays mail from sites within the local domain or subnetwork. In addition, the system administrator can set up access controls on the basis of client host names/addresses, and on names or mail addresses that are exchanged via SMTP commands. 1 - Claim: Postfix relay restrictions can be bypassed with forged PTR records. Response: in my opinion, the current measures raise the bar to a sufficient level. Postfix uses a world-readable/writable/executable, sticky maildrop queue directory for locally-posted mail. Postfix uses world write permission to avoid the need for set-uid/gid posting software. The Postfix queue directory is world-readable because queue file names are not strong secrets. 2 - Claim: local users can slow down Postfix by flooding the maildrop directory. Response: local users have lots of means to slow down the entire machine, not just Postfix. Standard UNIX accounting facilities can be used to expose the culprit. Once the sysadmin has found and shot him/her/it, Postfix will catch up. 3 - Claim: local users can see Postfix maildrop queue files. Response: there is no loss of privacy. Local users cannot access the content of other user's Postfix maildrop queue files. Postfix has a "mailq" command that gives away more information. 4 - Claim: a local user can make hard links to Postfix maildrop queue files and thus prevent mail from being delivered. Response: the mail will be delivered. When a queue file has more than one hard link, Postfix deletes the hard link, and logs a warning. When the hard link count reaches 1, Postfix delivers the mail. See also claim #2. Standard UNIX accounting facilities can be used to expose the culprit. 5 - Claim: a local user can make a hard link to a mode 0700 file outside the maildrop directory and have that delivered as mail. Response: the file will not be delivered. See also claims #4 and #2. Postfix deletes the hard link in the maildrop queue directory, and logs a warning. In addition to this, Postfix queue files have a very specific file format that is produced by no other software, and Postfix insists that queue file records be written in a very specific order. Postfix deletes queue files that do not satisfy all requirements. Standard UNIX accounting facilities can be used to expose the culprit. 6 - Claim: a local user can chown files and impersonate another user. Response: Postfix uses the queue file numerical uid for logging purposes only. Standard UNIX accounting facilities can be used to expose the real culprit. The unauthenticated SMTP protocol provides much more effective means for impersonation. 7 - Claim: world-writable directories are the cause of more vulnerabilities than set-uid programs. Response: both world-writable directories and set-uid/gid programs require a great deal of care. This is a matter of taste, not of dispute.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:25:22 PDT