OT: Root access policy

[Damien Fleuriot]

On 12/29/11 10:58 AM, Polytropon wrote:
> On Thu, 29 Dec 2011 04:01:42 -0500, Irk Ed wrote:
>> For the first time, a customer is asking me for root access to said
>> customer's servers.
> 
> Customer + root at server == !go; :-)
> 
> 
> 
>> Obviously, I must comply. At the same time, I cannot continue be
>> accountable for those servers.
> 
> Fully correct. Check the contract you made with the
> customer regarding responsibility and conclusions.
> 

Another way of doing things would be to give the customer root access on
the server, if it's entirely his, and relinquish your own root access.

No more root access for you, no accountability considerations.


> 
> 
>> Is this that simple and clear cut?
> 
> I'd think so. Maybe changing the contract is
> required.
> 
> 
> 
>> Assuming that I'll be asked to continue administering said servers, I guess
>> I should at least enable accounting...
> 
> You could have better success using sudo. Make sure
> the customer is allowed to "sudo <command>". The
> sudo program will log _all_ things the customer
> does, so you can be sure you can review actions.
> Furthermore you don't need to give him the _real_
> root password. He won't be able to "su root" or
> to login as root, _real_ root. But he can use
> the "sudo" prefix to issue commands "with root
> privileges".
> 

"sudo su -" or "sudo sh" and the customer gets a native root shell which
does *not* log commands !


> 
> 
>> I'd appreciate comments/experience/advice from the wise...
> 
> Just a thought: "Parallel administration" (you _and_
> the customer), both capable of using the power of
> the root password, can lead to trouble. Avoid it
> whenever possible, use "sudo" to satisfy the
> demands of the customer. And make sure that - as
> he now posesses immense power - you regulate the
> responsibilities by CONTRACT: _you_ are not
> responsible if he does "sudo rm -rf /" or
> something similar.
> 

Sadly, this brings in the burden of proof.
As in, prove that *he* didn't issue the dumb command, the customer did.

This model is endangered by the commands I cited above :/


> I'd give the customer only that much access as
> he actually needs. "Role based models" such as
> they can be done without root passwords
> (tools: sudo, super) can help here.
> 

That's more like it indeed, however it still poses security threats.

Say the customer can sudo commands located in /usr/local/libexec/CUSTOMER/

All he has to do is write a simple link to sh/bash, and sudo it.