[814] in linux-security and linux-alert archive
Re: [linux-security] Admin note (recent traffic surge).
daemon@ATHENA.MIT.EDU (JaDe)
Mon Jun 17 09:57:41 1996
From: jadestar@netcom.com (JaDe)
To: woody@altair.stmarys-ca.edu (Woody Weaver)
Date: Fri, 14 Jun 1996 16:00:53 -0700 (PDT)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <m0uTbSu-0005KYC@altair.stmarys-ca.edu> from "Woody Weaver" at Jun 11, 96 02:59:00 pm
> I have one question about uid 0 accounts. Of course one wants to give
> minimum permissions to accounts, and the more uid 0 passwords floating
> around the more risks one takes. Generally, the "all the eggs in one
> basket and watch that basket very closely" is a good idea. However,
> as one author noted, if you permit a novice to su and do work, there
> is a possibility that they might do something that prevents normal use
> of the system, such as accidentally changing the root password.
>
I recommend two root accounts (root and 'toor' or 'ruut' or
whatever). The one root account is "normal" and used by
all who need root access. The other gets a random string
as a password -- this is hand written onto paper after being
generated and the paper is sealed in a "security" envelope
and locked in a safe (i.e. forget about it until "normal"
root's account is dead).
For the other one I suggest that only *one* person
(the primary admin) has the real password.
Everyone else that needs root access uses 'sudo su -'
(they use *their own* password to become root).
Wherever possible these other administrators actually
aren't even allowed a direct root shell -- they
execute sudo scripts that just provide them access to
the commands that they really need (add.a.user,
change.a.passwd, edit.aliases, etc).
The advantages to this approach are in accountability.
Each use of any root shell or script by any of the admins
is logged (preferably to a remote, more secure machine).
By having sudo in place -- and by examining the logs of
usage (all su shell sessions should be running 'script')
you can incrementally tighten up the security (by
identifying what your admin team is *really doing* as root
and scripting each part of it as possible).
The sad reality of administering a multi-user Unix host
(as opposed to a workstation, or a server) is that there are
too many administrative tasks with require root access
for which is *should* be possible to delegate to trusted
admins. (This happens to a lesser degree in Netware and
to an even greater degree in NT and probably in varying
degrees in other systems).
'sudo' is no panacea (any scripts you write are subject
to the same potential bugs as an SUID script) the
main advantages are that you limit who uses the script
(without a *shared* password), and you get logging
for free.
I've set up certain "psuedo accounts" (like the 'mlist'
"Mail List Manager" and 'postgres' "Postgres DB Admin")
with a '*' password and configured the system to only
allow 'sudo su - ... ' to access those accounts. I've
even considered making the 'root' password '*' and
using the same technique (been to busy/timid to try that
yet).
Does anyone know of potential problems with this approach?
Does anyone on this list have suggestions or caveats for
those of us that are still learning 'sudo'?
Can anyone offer us some reasonable alternatives for
delegating/distributing *limited* administrative
functions?
