[ On Monday, September 4, 2000 at 09:59:33 (+0100), Philip Hazel wrote: ]
> Subject: Re: [Exim] Does Exim have security problems?
>
> 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;
This is good -- I'm sorry I was not aware of this option before!
> 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).
Yes, indeed it is often the case that root will not necessarily have
access to user files if they are on an NFS-mounted filesystem.
I've decided though that if the user root's remote access privileges
have been mapped to does not also have access to the user .forward files
then the mailer should just ignore them as if they do not exist. I
haven't yet found anyone who can make a strong enough claim that will
convince me otherwise. There should be nothing secret in them, after
all. So in general I don't worry about root not being able to open and
read the .forward files.
> 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.)
You're right, actually reading the users' ~/.forward files is not a
security issue in itself.
As well in the case where the .forward file can contain constructs that
lead the mailer into writing to a file or running some process it is of
course quite important (at least it's very likely quite important w.r.t.
most sane security policies) that the apparent owner of the mailbox in
question have properly authorised this operation. So indeed I think
it's still a good idea to ensure that a .forward file's ownership and
permissions are such that the mailer can ensure the operations it is
about to perform on behalf of the owner of the mailbox are indeed
authorised.
> > 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.
I should be careful to look for double negatives in what I write -- they
make lots of sense to the author at the time, but they can be stumbling
blocks to understanding....
> 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.)
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.
The problem is of course that the original set-user-ID design doesn't
really require that the system change the way the user is allowed to
interact with a process he or she has ownership of. For example the
user may have write access to the process address space and in
combination with an executable stack area the user will be easily able
to modify the behaviour of the process and control its actions when it
regains its privileges. Slowly systems that have continued to support
seteuid() and setreuid() have been modified to introduce new rules that
prevent certain operations on processes that initially had privileged
status, but it seems that every so often systems introduce new features
that make (incorrect) assumptions about various security-related
issues.
Without that middle ground there is no room for errors to be made, and
indeed history has shown that errors are not just possible but common.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
