[ On Tuesday, September 5, 2000 at 09:29:37 (+0100), Philip Hazel wrote: ]
> Subject: Re: [Exim] Does Exim have security problems?
>
> On Mon, 4 Sep 2000, Greg A. Woods wrote:
>
> > With seteuid() [and its earlier form setreuid()] it has been found to be
> > possible, on several types of systems, for an ordinary user to modify
> > the process, or play other tricks, during the time when it has dropped
> > its privileges such that when it regains its privileges (either in the
> > normal fashion, or now in the control of the user) it will perform
> > actions that the programmer had not intended.
>
> Sure. But in the case of Exim's use of seteuid, the alternative is to
> let it run on as root, but otherwise run exactly the same code. If the
> user can modify the process address space, they are going to be able to
> break things just as easily. I think what I am saying is that Exim's use
> of seteuid is not for protection against users, but for protection
> against itself. For protection against users, it uses setuid.
>
> This has been a useful discussion. It has further clarified my thinking
> about these issues. When I get to considering some long-term strategy
> for Exim, I'll think further about this.
Note that the user will only be able to play tricks with the exim
process (such as perhaps writing to its address space on those systems
that make the mistake of allowing this) during the time when when the
process has dropped its privileges, eg. after it calls:
seteuid(real_uid);
/* ... process may now be vulnerable ... */
While running as root the process is only vulnerable to the usual set of
programming mistakes, as the process address space will most likely not
be writable by the user, etc. (I.e. contrary to several known bugs with
seteuid() in several systems of radically different heritage, there
haven't ever been many bugs that made ordinary setuid processes
vulnerable.)
To be truly safe in honouring the Unix security model one must totally
disable the seteuid()'s ability to restore superuser privileges, and to
disable it right in the kernel itself.
One could also disable all of the features that have lead to
vulnerabilities in seteuid(), such as ptrace, /proc, etc., but that
seems more like cutting off your nose to spite your face....
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
