[ On Friday, September 1, 2000 at 11:49:49 (+0100), Philip Hazel wrote: ]
> Subject: Re: [Exim] Does Exim have security problems?
>
> On Tue, 29 Aug 2000, Jeffrey Goldberg wrote:
>
> > That is not entirely true. Exim processes *permanently* discard
> > privileges, if I understand correctly.
>
> Sometimes, depending on why they are discarding it. For local
> deliveries, receiving a message, and the daemon, it is permanent. For
> reading a user's .forward file, it is temporary.
This is the only problem I have with Exim's current implementation.
A correct and 100% safe implementation of the Unix security model in any
given kernel implementation MUST make it impossible for any process that
was started as a set-user-id "root" program to not *permanently* give up
its superuser privileges. This requirement is fundamental to the
success of the Unix setuid/process model with a single privileged user.
(I'm even wary of the ability of a setuid-unprivileged process to swap
real and effective user-ids repeatedly, but at least then the entire
system's security cannot be compromised and there is no loss of
accountability from a compromise.)
There are just too many ways for a user to affect what a setuid program
does by carefully managing its execution environment, and when that
program is setuid-root the consequences are a root exploit with no
accountability remaining in the system. Even when it is known that the
text segments of a process are guaranteed to be read-only (most systems
ensure this now), and even when the stack is not executable (not very
many systems do this yet), there are still many many ways to trick a
setuid program into regaining its privileges in unexpected ways that
allow the user to manipulate it into doing something it should not do.
The more complex the program then the more ways there are to manipulate
it too!
Just because any given system allows a setuid program to give up and
then regain its privileges dosn't mean that it's safe for an application
to take advantage of this misfeature. (i.e. seteuid(2) and setreuid(2)
violate the Unix security model, and in at least Solaris-2.x (up to
x==3?) and some versions of Linux they were a wide open hole with the
only thing worse being the old bug in some SysV/i386 machines that left
the 'u' structure unprotected in the process address space!)
I was finally able to fix Smail so that it honours the Unix security
model without deviation. Here's the comment from smail's src/sysdep.c
fopen_as_user() function describing the correct way for a setuid-root
program to safely examine a file without abusing its privileges. Note a
full fork() is necessary.
/*
* This is the classic way for a setuid program to use a file safely as a
* user without worrying about race conditions. If the file doesn't exist
* we first must create it as the user. In all cases we then open the file
* first as root (no create, no truncation unless the file is to be owned
* by root), then as the user in a child process, and we compare st_dev and
* st_ino for both files, failing if they are not identical.
*/
Once the child process has verified the file already opened by the
parent is indeed the same file that it opened, and of course that it was
indeed permitted to open the file after it had relinquished its
privileges, then, and only then, it is safe for the parent process to
use the already open file descriptor.
Note also that on all modern Unix and Unix-like systems the overhead of
the fork() system call is not too much of a burden to pay for robust
security. Note also that there are just too many possible ways for
vfork() to be incorrectly implemented for it to be safe to use in a
security sensitive application.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
