[ On Sunday, June 17, 2001 at 20:04:52 (-0400), Rick Byers wrote: ]
> Subject: Exim allways runs as root
>
> So my question is, should patch-ab be change to set EXIM_UID to 'mail' or
> should the MESSAGE be changed to remove the instructions about the mail
> user.  Personally, I like the idea of running as a non-root user as much
> as possible, especially since the exim docs reccomend it.

Note that there's very very very little gain to running a process as
non-root if you leave it with the capability of regaining root
privilveges at any time.  In fact there may (depending on external
circumstance) actually be FAR more risk in doing so!  A tiny and almost
insignificant example of this kind problem is represented in the recent
kernel-based race condition bug which allowed a setuid process to be
traced before the P_SUID flag was set.

In something long-lived like exim if there's any glimmer of a chance of
running unauthorised code (eg. a buffer or format-string overflow) then
that new code need only do whatever's necessary to raise itself to root
privileges before forking a shell or whatever and voila, instant (and
possibly remote) root exploit!

I.e. telling any root-privileged process, eg. a mailer like exim, smail,
or sendmail, to run as a non-root user whenever it can is an almost
pointless excercise in futility and leads to a false sense of security.
The only exploits it will stop are the totally stupid ones that haven't
been coded with this inevitable need in mind.

If any process which needs root privileges when it starts but never at
any later time, does not totally, permanently, and forever give up its
privileges as soon as possible, then it may as well never do so.  At
least then the programmer might have enough incentive to continue
programming every single line with the necessary care and attention to
detail that all privileged programs require.

Unfortunately not all unix and unix-like operating systems provide easy
and fool-proof mechanisms for permanently giving up root privileges.
IMNSHO the mere ability to raise root privileges after initially giving
them up should be impossible in all systems (not using it in a program
is not sufficient -- the kernel must prevent it from the outset).  I
have hacked the worst of such dangerous capabilities from my own kernel,
and replaced them with kernel logged warnings that calling program needs
fixing.  OpenSSH and kermit are the only offenders I've used to date.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>