On Tue, 5 Aug 2003, Harald Meland wrote:
> In Exim 2, the '/'-less first element of the require_files section was
> interpreted as a username, and caused the existence test for later
> elements to be done under the UID of that user.
>
> >From looking at the function check_files() in src/route.c, it appears
> that this is no longer the case. The function will now try doing a
> stat() of any file elements it finds *without* changing (effective)
> uid.
That is true - because I wanted not to make any use of the seteuid()
function in Exim, for better security.
> Re-reading the latest Exim specification, I can sort of see that the
> behaviour I'm experiencing is documented. And, indeed, the
> behaviooral change is listed rather explicitly in Exim4.upgrade.
The code is still supposed to do some checking, by scanning the
components of the path of the file, and checking the access permissions.
Is this not sufficient for your requirement? (I presume it is
working...)
> If I'm *not* missing anything: Can anyone tell me why running as root
> while routing is better (securitywise, the Exim4.upgrade file makes me
> presume) than using seteuid?
After many years of wondering why security people didn't like seteuid, I
finally understood the problem a couple of years ago. The insecurity
arises when a program behaves like this:
... running as root
seteuid to something other than root
... do some stuff
seteuid back to root
... carry on
During the time that the program is not running as root, any *other*
program that is running as that euid will have access to the process,
and could in principle modify the contents of its address space. Then,
when the program returns to being root, it might do unwanted things.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
