RE: [Exim] Root is user in Envelope

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Exim Users Mailing List
Fecha:  
A: Exim Users Mailing List
Asunto: RE: [Exim] Root is user in Envelope
[ On Monday, January 14, 2002 at 14:39:05 (-0000), Paul Walsh wrote: ]
> Subject: RE: [Exim] Root is user in Envelope
>
> Correct me if I'm wrong, but I was under the impression it was considered a
> BAD IDEA to have more than one user with the same UID _ESPECIALLY_ UID 0.
> If the remote admin requires root privileges then he should su to root (and
> thereby have his access logged in sulog). Every bit of advice I've read on
> UNIX security has strongly advised against sharing UID 0 between accounts.
> Paul Walsh


There are good things and there are bad things about it, and some of
them depend on what kind of system we're talking about.

The whole idea of user-IDs is to ensure accountability, which is one of
the three main foundations of computer security. Accountability is the
ability to know which real human user is responsible for various actions
taken within the system. The user-ID is a translation of a real-world
identity into a virutual identity.

Multiple superuser accounts can be useful if you need to grant more
temprorary superuser access to someone or some group without divulging
the current "root" password, and without having to change it (which
necessitates communicating the new one twice in what might be a shorter
than normal change cycle, and which thus increases the risk that the new
one will be written down, or given out to the wrong person, etc.).

The problem with the superuser account (i.e. any account with a user-ID
number of zero in a unix/posix system) is that it's generally a shared
account. This means every user of that account should be forced to
leave an audit trail of how they accessed the account (thus the 'su').
The only time anyone should ever login to the "root" account directly is
when they've physically passed through some real-world security
mechanism to assure their accountability (eg. into a pass-card protected
computer room where their entry is logged on a printout, etc.).

The usual problems with having multiple superuser accounts is that
there's really only one from the kernel's perspective (user-names are
not used in the kernel, only the magic number zero), and it's also
generally impossible to guarantee that indiviuals only ever use one and
only one superuser account. The latter can be mitigated by using
kerberos and its concept of root instances, but that presumes you have
the infrastructure necessary to build a secure kerberos KDC, etc.
the former is somewhat mitigated if you have a secure log host and you
are reasonably

Now of course most discussions about computer security degrade into
silly debates about some fictional concept we seem to all have about
absolute systems security, such as my own above. :-)

In the real world it's often sufficient to make a number of
generalisations. For example you might simply make a security policy
rule that all your system managers will always use 'su' no matter how
many superuser accounts you have, unless they're in front of the
physical machine console, in which case they'll write their own log
entry in the physical system log book sitting beside the console. So
long as you have two or more system managers then peer pressure alone
(maybe with a few actual audits thrown in at random) will usually
suffice to keep everyone above board.

--
                                Greg A. Woods


+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>