From owner-freebsd-questions@FreeBSD.ORG Thu Dec 29 10:37:41 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE6E106566C for ; Thu, 29 Dec 2011 10:37:41 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4F71F8FC08 for ; Thu, 29 Dec 2011 10:37:41 +0000 (UTC) Received: from r56.edvax.de (port-92-195-18-127.dynamic.qsc.de [92.195.18.127]) by mx02.qsc.de (Postfix) with ESMTP id CC3EA1E255; Thu, 29 Dec 2011 11:37:39 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id pBTAbd7d002039; Thu, 29 Dec 2011 11:37:39 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Thu, 29 Dec 2011 11:37:39 +0100 From: Polytropon To: Damien Fleuriot Message-Id: <20111229113739.b532f139.freebsd@edvax.de> In-Reply-To: <4EFC3FA3.1060603@my.gd> References: <20111229105847.e15848ba.freebsd@edvax.de> <4EFC3FA3.1060603@my.gd> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: OT: Root access policy X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 10:37:42 -0000 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, ...