On Fri, 1 Sep 2000, Greg A. Woods wrote:
> > 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.
If you configure it with security=setuid then it won't use seteuid; it
will just try to read the file as root instead. The particular instance
of .forward files is not (in my view) a security thing; the reason for
using seteuid is so that it can read them when they are on NFS-mounted
file systems that are exported without root privilege (so root can't
read them).
You may have a different view of this, but I don't see the reading of
users' .forward files as a security issue. The sysadmin has configured
Exim to look for these files; I don't feel there is any implication of
"the user must be able to read the file" in the same way that there is
for the writing of mailboxes. (There are, of course, Exim options for
checking the owner, group, and mode of the file, but nowadays I'm not
convinced that these checks are really worth it.)
> 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.
That double negative had me confused for a bit, but I think I see what
you mean, namely: Either a processes hangs on to being root, or it gives
up the privilege for ever. Period. No middle way. That is, pretty
obviously, a cleaner and presumably less error-prone paradigm. In terms
of today's systems, it means using setuid only, not seteuid. As I said
above, you can run Exim without using seteuid if you want to. Indeed,
very early versions of Exim were like that, and made no use of seteuid.
Then somebody said to me "What do you lose by calling seteuid(exim)
while running the directors and routers? It must gain you a bit of
protection against coding errors." Is there an argument against that?
(And later came the point about non-root-exported NFS .forward files.)
> 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.
That is true. That is why Exim gives up the privilege permanently when
it really matters most (all actual deliveries, all message reception).
> 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.
I was about to say "Exim does not use vfork()" but I see that it does in
the case when it is about to re-exec Exim in order to delivery another
message down the same socket. Certainly in the case of a local delivery,
it uses fork (and then setuid).
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
