[ On Tuesday, March 30, 2004 at 07:44:31 (+0200), Marten Lehmann wrote: ]
> Subject: Re: [Exim] why is exim adding headers?
>
> > No, really, don't do that. The "nobody" user is supposed to have
> > absolutely no priveleges. That's the whole point of it.
>
> I did and it worked. As of linux, nobody may be intended to have no
> priveleges, but in fact it has the some as any other user has. Nobody
> can simply be "nobody". Please explain how any any user or any service
> running at a different userid shall get nobody-privileges?
First off it's _very_ important to understand that "privilege" in any
Unix-like system (or any other similar system where files are everything
and the set-user-id-on-execution trick is used) has everything to do
with file permissions and ownerships. What a process running with a
given UID and GID(s) can do entirely depends on what files it can access.
(though many systems still ignore most forms of network access as a
privileged act :-)
Now a history lesson:
In the good old days when Sun invented "nobody", the idea was that
"nobody" would never (no, that's not a double-negative) own any
(important) files and thus would only ever be able to write to
world-writable files and create files in world-writable directories
(e.g. /tmp and /var/tmp); and of course he/she/it would only be able to
read from world-readable files and search world-readable directories.
This was of course all invented so that NFS clients couldn't quite so
easily take over superuser privileges on the NFS server since all
attempts by root on any client would appear to be coming from the
"nobody" UID[1]. Sun carefully chose "-2" as the UID for the
"nobody"[1] user since that way it would be almost impossible for any
real user to collide with this special use and thus even if someone
stupidly deleted the "nobody" account, the server would still be
relatively assured of the same level of security.
Then some bright-eyed bushy-tailed young in-experienced know-it-alls
thought that overloading the NFS "nobody" user with the duties of
running programs for arbitrary unauthenticated and unauthorised network
clients, such as SMTP clients.
With the boom of the WWW it got so bad that many completely naive
systems integrators were setting up HTTP servers to run CGI scripts as
"nobody" and then discovering that they had to make certain files
accessible by "nobody". All's still relatively OK, since NFS isn't
quite ubiquitous despite Sun's best efforts to make it pervasive ("The
Network is the Computer(TM)" and all that....), and computers have been
come economical enough to have dedicated purposes (one for HTTP, and a
whole separate machine for SMTP, etc.).
However to anyone who's been paying attention to security incidents over
recent years it should be abundantly clear that we need many unique
"nobody" equivalents -- one for each specific purpose, and some of them
won't quite be "nobody", but in fact may have some restricted privileges.
So, in fact the UID that Exim uses as an "unprivileged user" should
really be a unique exim-specific user-ID. If your systems running Exim
don't use NFS[3], and if they don't already use the "nobody" account for
any other purpose, then it's OK to use "nobody" for Exim, but keep in
mind that systems are rarely static and this choice may affect the
future status of the system. I.e. there can be many "unprivileged
users" on any given system, and it's important to keep them distinct
from each other lest some outsider exploit their connectedness to
possibly gain unauthorised privileges. Indeed it may even be desirable
or necessary in some scenarios to have several unprivileged (or least
privileged) users for various unique e-mail uses, and then have another
unprivileged user for the default use of Exim.
[1] Many folks fail to understand that NFS security issues go much
deeper than UID mapping. Also many systems have no real username
for the "-2" account and the "nobody" account is unique and separate
from all things NFS (unless the client root IDs are explicitly
mapped to the username "nobody").
[2] Modern NFS implementations usually allow the root users to be mapped
to user-specified UIDs, sometimes even on a per-mount basis.
[3] Some claim NFS should never get anywhere near any mail server of any
kind.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
