Subject: Re: Exim allways runs as root
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.ORG>
From: Rick Byers <RickB@BigScaryChildren.net>
Date: 06/17/2001 21:43:32
I agree with you, I was wondering what the motivation was for temporarily
giving up root priveledges. However, if configured for a non-root user,
Exim will PERMANANTLY give up root priveledges when receiving a message.
Of course then it has to invoke a new exim process to actually deliver the
message since it no longer has permission to do so. I'm not sure if any
significant amount of code runs permanantly without root, but incase it
does - I'll continue using "security=setuid'. I just hope the authors of
Exim have been really carefull about security.
By the way, I was going to just upgrade IAW to the latest Smail but
noticed that even the Smail README said "you should upgrade to something
newer like Exim". Do you and the rest of Planix prefer something other
than Smail for your customers now then, and if so - what?
On Sun, 17 Jun 2001, Greg A. Woods wrote:
> [ 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 <email@example.com> <firstname.lastname@example.org>
> Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>