[geeks] root equivalent user

[Greg A. Woods]

[ On Thursday, October 24, 2002 at 22:18:06 (-0400), Kurt Huhn wrote: ]
> Subject: Re: [geeks] root equivalent user
>
> So, what would *you* do, Greg?  The world awaits your wisdom...

Well first of all I write policies that deal with these issues and which
dovetail into overall security policies for the organisation as a whole.

Generally speaking though I trust people with the root password when
necessary, though of course only after doing whatever might be
appropriate for a background check and after giving them any remedial
instruction and reminders that might be necessary.

Where changing the root password is inconvenient (from a security
perspective) I create a new account with UID==0 and assign it a unique
new password that I give to the person.

When that person only needs root access temporarily (eg. as a contractor
or temporary assistant) then I change the root/altroot password after
they're done (or just lock the altroot account until it's needed again).

In larger networked environments where technically competent people can
be trusted with root access to their own workstations then I use
Kerberos and assign root instances to each user (while keeping the real
root password for sysadmins only).

I usually do not allow direct root logins except on the console (or
other trusted hard-wired terminals), and then only in emergencies.
Everyone must login to their own personal and unique accounts and then
they must su.  Personal accounts of those in the wheel group must be
kept just as secure as the root account must be kept.

(I would consider direct root logins via ssh with strong public key
authentication only and to unique per-person UID==0 accounts, and
disallow su in such a situation, if the situation required what little
extra accountabilty and control this offers and also to avoid some risk
of vulnerabilities in the on-system accounts of the administrators --
they would only use private and highly trusted workstations to connect
to the target system.)

In clustered server environments build an administrator-only server.
Trusted users on that server are allowed to start jobs on any other
server using only host-based authentication.  If untrusted people might
have any type of access to the LAN in such environments then I implement
an administrative LAN and host-auth'ed connections must goes over the
admin-only LAN.

Of course the devil is in the details and it would take a rather thick
book to write them all out (and I use several such books as references
myself! :-).

Accountability is key and is as important as authentication and
authorisation controls and integrity, yet it's the weakest link in the
average unix(-like) system today, and often just as weak a link in
real-world security too.

Just as Mike said, you can't have absolute security.  But then security
isn't a state that you reach, or even really a level that you can
balance with a risk assessment -- it's a state of mind and a way of
doing things.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods at ieee.org>;           <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>