This is an invitation for constructive discussion regarding the
merits of world-writable maildrop directories versus set-uid or
set-gid posting agents.
The Postfix design takes an unusual approach. In the light of
experience, I have no difficulty making changes to the design, but
I want to make an informed decision.
World-writable maildrop directories
-----------------------------------
Postfix uses a world-writable maildrop directory with an unprivileged
posting agent. Other systems use protected directories and set-uid/gid
posting agents.
The attacks on a world-writable maildrop directory are: 1) any
local user can flood the maildrop directory, 2) any local user can
hard link files to the maildrop directory (from maildrop or from
elsewhere), and 3) any local user can hard link files from the
maildrop directory to other directories. I will ignore attacks
that require systems with unrestricted chown.
Attack 1 is an annoyance. Just like filling up /tmp or /var/tmp.
Using a set-uid/gid posting agent does not prevent an attacker from
filling up the queue directory. However, set-uid/gid posting agents
do provide easier accountability.
Attack 2 is a wash. Postfix deletes a queue file that has multiple
links, so that the link count goes down; Postfix delivers a queue
file that has one hard link and that satisfies the Postfix-specific
record structure and record sequence requirements; Postfix discards
any other queue file.
I made a stupid oversight by missing 3). Postfix deletes the queue
file from the queue and the mail is not delivered. In order to stop
this attack one would have to keep maildrop queue file names secret.
The first step is to revoke directory read permission. The second
step is to choose file names from a sufficiently large name space.
Currently, the name space is about 2^15, but then the original goal
was not to keep queue file names secret. That can be changed.
The final consideration is robustness against change. Given that
this scheme uses only directory permissions and file names, I expect
it to be robust against changes in the operating system environment.
Set-uid/gid posting agents
--------------------------
If a world-writable maildrop directory can be attacked, what about
set-uid/gid programs? My concern is with the large amount of control
that an attacker has over a set-uid/gid process. Except for memory
mappings, almost all other process attributes are under control by
the attacker: process id, command-line array, environment array,
current directory, open files, process groups, process credentials,
resource limits, default file protections, scheduling priority,
signal disposition, timers, and so on; the exact list is system
dependent. That is a fair amount of control, and that is precisely
why writing a set-uid/gid program requires a great deal of care.
What about robustness against change? Writing a secure set-uid/gid
program is not sufficient. Examples abound of existing set-uid/gid
programs that became vulnerable after changes to the UNIX system:
for example, the introduction of shared libraries, or the introduction
of the /proc file system. It may be possible to write a set-uid/gid
program that is secure on today's UNIX systems, but the security
can fly out the window after any change.
Future direction
----------------
I see two directions for Postfix evolution: 1) maintain the present
world-writable maildrop and unprivileged posting agent and 2) use
a protected directory and a set-gid posting agent (set-uid seems
to have no obvious advantage here). Is it feasible to keep maildrop
queue file names secret, and are the other attacks indeed mere
annoyances? Is it feasible to write secure set-gid programs that
are not only secure today, but that will be secure on tomorrow's
UNIX systems as well?
Your feedback is appreciated.
Wietse
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:25:47 PDT