[ On Thu, May 8, 1997 at 00:47:44 (+0100), Jon Peatfield wrote: ]
> Subject: Re: Which is more secure?
>
> In the case of the setuid() code, exim must re-exec itself to gain root privs,
> this may mean spending longer as root in terms of cycles spent, but the area
> (or it is volume?) of code executed as root is much smaller, and the means to
> break it much harder.
Indeed. Unless the process re-exec's itself to regain the privilege it
is in fact bypassing the one and only security mechanism that UNIX
provides to allow safe and controlled granting of privilege.
However the common way of designing a privileged daemon is for it to
normally run with privilege and to fork and drop to unprivileged state
when it does something to or with user-controlled data.
This is, of course, contrary to the general guideline of a setuid
process giving up its privilege as soon as possible after starting and
doing the majority of its work in an unprivileged state.
The daemon-like design of sendmail and those that have followed it, such
as smail-3, and exim, is very bad since it entails running a large body
of code for a long time in a privileged state. Sendmail and smail-3
have at long last been modified to fork, and in cases exec a tiny agent,
when doing the dangerous work of opening a user's files for writing.
Never the less all of these mailers are usually used in a scenario where
they continue to run a vast majority of their code in the highly
privileged state of the superuser.
Ideally a mailer daemon should only do the one thing where privilege is
necessary, and then it should forever give up its privilege, ideally by
forking the main process -- i.e. the privileged code should be
physically restricted to doing one, and only one, job. Smail-2 did
this, and indeed all native mailers shipped with AT&T UNIX SysV have
operated in this manner.
What I'm talking about, of course, is running the mailer as root only
long enough for it to open its SMTP port, and from then on running as
nobody.mail (this first job can even be done by a wrapper program).
This requires the user mailboxes pre-exist and never be removed, or that
the OS support chown() by unprivileged users.
Naturally the group mail should contain no users as it is the one
semi-privileged identity responsible for mailbox access control.
Of course with such a mailer configuration one gives up the generic
ability to deliver to programs as an arbitrary user (and thus the user
must ensure files opened by filters are group writable by the mailman),
though there have been agents written which could do this with some
degree of safety (Jon Zeef's lmail comes to mind, though I had
significantly hacked on it to secure it properly in my smail-2.7-beta
that was never really released).
It should be relatively trivial to modify exim so that it can run in
such an unprivileged state as I've described.
Note the most important aspect of what I'm describing is that the
exposure of the system to the mailer is reduced from that of the
continuous execution of a large and complex process in the kernel
privileged state; down to where the mailer runs with only the privilege
of a unique empty group used only to deliver mail.
Running a mailer as root is really just laziness. Yes, I do it too, but
I can at least claim that I've been forced into it by virtue of having
had to migrate to BSD systems in order to make it possible to run modern
software and to join the Internet. Hopefully I can help make it
possible, if not easy, to avoid the problems of the past. It seems it
has taken us a very long time to learn the lesson of 1988's events and
unfortunately the word is just starting to spread to the majority.
--
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
