root users

[Jeff Vian]

Cris Rhea wrote:

>>Here is a situation where this does not make sense, and the use of sudo 
>>does make sense
>>
>>1. Multiple users with root authority.
>>    john,     bill,  and   sam
>>
>>one of these 3 happens to get mad/upset/frustrated/careless
>>This user (lets say john) logs in and runs some commands that are very 
>>destructive to the system
>>       (have you ever heard of "rm -rf /" being run????)
>>All three users actions are recorded as being done by root, thus no way 
>>to track who did what or when.
>>The analysis of the problem shows that "root" did some 
>>dumb/careless/harmfull things to the system.
>>
>>Who is responsible?????       Answer: one of the above
>>
>>2. One closely guarded root account with multiple users allowed the same 
>>access with sudo.
>>    again,   users john, bill, and sam (but none of these users know the 
>>root password)
>>
>>The same user decides to do the dirty deed he did in the above scenario.
>>Sudo actions are logged by user name,  the user only has  limited 
>>privledges when not using sudo.
>>John now uses sudo to do his dirty work, and it is logged by user 
>>name/time/command
>>Analysis shows john did the nasty deed.
>>
>>Who is responsible?????    Answer:  john.
>>    
>>
>
>
>IMHO, sudo works great if you need to give out a very limited set of
>privs to a specific non-system admin (e.g., an applications programmer 
>responsible for a package that needs root privs to start).
>
>Also, IMHO, system admins need two things:
>
>    1. A clue as to what they're doing.
>
>    2. They need to be trustworthy and have the trust of management.
>
>If you have someone in your company who would intentionally destroy 
>a system with something like "rm -rf /", they have no business being a 
>system admin- period.
>  
>
I agree with both.

However, there is always the time when a trusted individual goes whacko, 
or for some other reason decides to do something that will hurt.  Or 
when someone who has high level access decides to use it for something 
other than his job with the expectation of not getting caught. 
(industrial espionage anyone?)

Have you ever hears of the common procedure in the IT industry where 
when an employee gives a 2 week notice they are often excorted to the 
door and paid for the 2 weeks?  Or the case where an employee being let 
go is handed his notice and escorted out?

These are simple security features/procedures based on what might (or in 
some cases has) happen if they are allowed access under less than ideal 
conditions.

Bottom line:  Security procedures and policies often come at the cost of 
some inconveniences.
You sacrifice some security or you sacrifice some convenience.  Your 
choice what is right for you.

Jeff

>It all comes down to trust. You need to be able to trust your system admins. 
>If you can't, your company has real problems.
>
>Having multiple root logins is no big deal if someone isn't trying to
>cover things up.  There are lots of logs that indicate which "root login"
>was active at the time.  If you have someone intentionally covering things 
>up, they can modify the log files too... :)
>
>Yes, accidents happen, but a real system admin takes responsibility for
>an "Oops" and fixes things. A really, really good system admin fixes things
>before anybody figures out things are broken... :)
>
>Junior system admins should not have access to critical, production servers.
>They should hone their "root" skills by building servers (prior to going
>production) under the mentorship of a senior admin. The next step would be
>to manage non-critical servers themselves (again, under the mentorship of 
>a senior admin). A responsible admin knows their limits and asks for help
>if they get into a situation over their head.
>
>My $0.02.
>
>--- Cris
>  
>
All good points.

>  
>