RE: OT: Root access policy
> -Original Message- > From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- > questi...@freebsd.org] On Behalf Of Polytropon > Sent: Thursday, December 29, 2011 9:58 AM > To: Carl Johnson > Cc: freebsd-questions@freebsd.org > Subject: Re: OT: Root access policy > > On Thu, 29 Dec 2011 09:15:45 -0800, Carl Johnson wrote: > > Damien Fleuriot writes: > > > > > 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. > > >> > > > > >>> 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 ". 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 ! > > > > The sudoers manpage mention the noexec option which is designed to > > help with the first problem. They also show an example using !SHELLS > > which can help with the second. > > It's also worth mentioning "super" again - as an alternative to "sudo". But after all, > if restricted in any way, both of them are _not_ requivalent to "full root access" > (equals: root + root's password) which the customer initially demanded. > I highly recommend reading audit(4) and then audit(8) (in that order). This will catch more security instances than simply relying on sudo(8) logging -- which won't catch any commands once the user has "become root" (ala "sudo su -" for example). Once upon a time (RELENG_4), we used a kernel module named "lrexec" which logged all system calls to exec(3) family of functions, but it was too verbose. audit(4) replaces our need for lrexec. -- Devin > > > -- > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: OT: Root access policy
On Thu, 29 Dec 2011 09:15:45 -0800, Carl Johnson wrote: > Damien Fleuriot writes: > > > 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. > >> > > >>> 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 ". 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 ! > > The sudoers manpage mention the noexec option which is designed to help > with the first problem. They also show an example using !SHELLS which > can help with the second. It's also worth mentioning "super" again - as an alternative to "sudo". But after all, if restricted in any way, both of them are _not_ requivalent to "full root access" (equals: root + root's password) which the customer initially demanded. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: OT: Root access policy
On Thu, Dec 29, 2011 at 10:01 AM, Irk Ed wrote: > For the first time, a customer is asking me for root access to said > customer's servers. Are we talking about jail(8)- or server-level root access? -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: OT: Root access policy
Damien Fleuriot writes: > 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. >> >>> 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 ". 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 ! The sudoers manpage mention the noexec option which is designed to help with the first problem. They also show an example using !SHELLS which can help with the second. -- Carl Johnsonca...@peak.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: OT: Root access policy
On Dec 29, 2011, at 4:01 AM, Irk Ed wrote: > For the first time, a customer is asking me for root access to said > customer's servers. > > Obviously, I must comply. At the same time, I cannot continue be > accountable for those servers. > > Is this that simple and clear cut? > > Assuming that I'll be asked to continue administering said servers, I guess > I should at least enable accounting... > > I'd appreciate comments/experience/advice from the wise... Call me paranoid but is your contract near term end? In my experience this is usually a precursor to a end of year cost cutting service provider change. Specifically someone in sales's second cousin's nephew who saw a linux server once and thinks he's an expert. I recommend that you complete a backup of everything prior to granting them sudo access. Possibly even run am md5sum against all important config files and save that in your back up as well. Then give them well written explanation of why sudo is superior or at least safer to direct root access. Regards, Mikel King BSD News Network http://bsdnews.net skype: mikel.king http://twitter.com/mikelking ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: OT: Root access policy
On Thursday 29 December 2011, Damien Fleuriot wrote: [snip] > "sudo su -" or "sudo sh" and the customer gets a native root shell > which does *not* log commands ! [snip] > 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. But if it's possible to determine exactly what commands the customer needs to run as root then putting suitable incantations into /usr/local/etc/sudoers should prevent the customer from being able to use tricks like that. -- Mike Clarke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: OT: Root access policy
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 ! S!!! 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 s!!! 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, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: OT: Root access policy
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@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 ". 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: OT: Root access policy
On 29/12/2011 09:01, Irk Ed wrote: > For the first time, a customer is asking me for root access to said > customer's servers. > > Obviously, I must comply. At the same time, I cannot continue be > accountable for those servers. > > Is this that simple and clear cut? > > Assuming that I'll be asked to continue administering said servers, I guess > I should at least enable accounting... > > I'd appreciate comments/experience/advice from the wise... Where I used to work, customers were given root level access to their servers by default. We did insist on a secure access method using SSH keys and we also insisted that root level access was allowed only to specific named people each using their own SSH key (so you always had to login as an unprivileged user before getting root access). This allowed a good level of audit trail and the ability to identify exactly who had done what. On the whole, this worked well. Most customers are after all motivated to keep their servers running well and securely and would very rarely use their root level access, since we would provide all the routine management functions as part of the service. Occasionally there would be customers that we pretty much as capable as we were, and for those we were happy to let them do their own thing so long as they conformed to our security standards. Occasionally there were the odd customers who thought they were much more capable than they were. Generally there would be a cock-up, which we would then sort out at the customers expense, after which things tended much more towards the customer leaving it all to us. (Usually this would happen during the system setup or testing phase so no embarrassing service outages.) On the other hand, we tended not to give customers any access to firewalls or network switches or other network infrastructure, nor indeed to monitoring or backup or other adjunct services. The important thing, especially if you have stringent service level guarantees in your contracts, is to disclaim any liabilities due to outages or other problems caused by customer action. Which implies that it is vital to have good audit data that can identify the individual responsible for any action. You're also justified in raising your prices to cover yourself against potential losses (reputational or otherwise) due to customer actions. Your mileage may vary -- the clients at that job were mostly finance or similar companies and tended to have quite formal change-management regimes in any case. Other sectors may be a lot more gung-ho... Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: OT: Root access policy
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@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. > 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 ". 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". > 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. 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. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
OT: Root access policy
For the first time, a customer is asking me for root access to said customer's servers. Obviously, I must comply. At the same time, I cannot continue be accountable for those servers. Is this that simple and clear cut? Assuming that I'll be asked to continue administering said servers, I guess I should at least enable accounting... I'd appreciate comments/experience/advice from the wise... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
