OT: Root access policy

[Polytropon]

On Thu, 29 Dec 2011 11:23:31 +0100, Damien Fleuriot wrote:
> On 12/29/11 10:58 AM, Polytropon wrote:
> > On Thu, 29 Dec 2011 04:01:42 -0500, Irk Ed wrote:
> >> 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.

Yes, that's the "other option". Full responsibility
to the customer (as per his demand of a root password),
no responsibility to the administrator anymore.



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

Shhhh!!! Don't tell them! :-)



> >> 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 :/

Ah shhhh!!! Don't point at it again! :-)

But you're fully right: The logging has ways to
get around it. I think "super" can be used to
give a narrowed-down access, but that's not
comparable to the customer demanding "root access"
(which it wouldn't be).



> > 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.

True, it does. You won't have full security as long
as the customer is able to do root-related things.



> 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.

Stop that! You're hacking the system by telling all
the secret things! :-)

Depending on the skills of the particular customer,
and of course in regards of what he _intends_ to do
himself, there are many possibilities. They even
get enlarged when the customer gives the root password
to a 3rd person, intendedly or by careless actions.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...