ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruth Hoffman <rhoff...@aesolves.com>
Subject Re: Multi-tenant Security
Date Sun, 29 Jan 2012 13:44:39 GMT
Hi Paul, David:
Thanks much for this further clarification.
Please do not think I'm not denigrating the implementation in any way.
I want to clearly articulate the alternatives to anyone who asks. And, 
many people have asked.
Thanks again.
Have a great day.

On 1/29/12 2:34 AM, David E Jones wrote:
> Paul is correct, the multi-tenant stuff has nothing to do with code
> deployment and tenants don't have access to code. If you use OFBiz in a
> multi-tenant mode all tenants will be running on the same code base.
> Whoever is managing that code base could write tenant-aware code so that
> it only operates for one or more tenants, but that would not be the
> tenant setting it up, it would be the group who controls the central
> code base.
> The confusion in your question, Ruth, seemed to be the the multi-tenant
> functionality somehow gives each tenant the ability to add code, and it
> does not.
> -David
> Paul Foxworthy wrote:
>> Hi Ruth,
>> Your bank does not provide you with your own personal mainframe and your own
>> personal database. Your bank balance is in a row in a table with other
>> customers' balances above and below, which you should not be able to
>> discover. We've been living with those risks for decades.
>> Of course, an OFBiz user with permissions to log on to OFBiz and use its
>> services should not have the rights to modify a classpath or upload a Groovy
>> script. An OFBiz user should not have write permission on anything that is
>> executable. That applies to single-tenant as well as multi-tenant
>> situations. It applies to web applications in general, not just OFBiz, not
>> just Java. If such an exploit were ever found, I would be willing to bet
>> that a single-tenant OFBiz would be vulnerable as much as a multi-tenant
>> OFBiz.
>> Any OFBiz site that is public-facing (for example, for e-commerce) might
>> have visitors who are hostile to the owner and seeking to exploit a security
>> flaw to do damage. That applies to single-tenant as well as multi-tenant
>> situations.
>> Multi-tenancy should not greatly increase the risk of these or other
>> exploits. You're running pretty well the same code, it's just a matter of
>> what database you're connected to.
>> So I don't see multi-tenant as a totally new or unique situation. It's a
>> difference of degree, not kind.
>> Cheers
>> Paul Foxworthy
>> Ruth Hoffman-2 wrote
>>> Hans, Pierre and several others have been kind enough to outline the
>>> OFBiz multi-tenant value proposition.
>>> I appreciate this primarily because I can't even count the number of
>>> times prospective OFBiz users have asked me about it. Now, with this
>>> background information, I feel comfortable articulating the marketing
>>> value proposition.
>>> What I still have great angst about, is the security side of
>>> multi-tenancy. Perhaps someone can clarify or answer this basic question:
>>> What is to stop a hacker or otherwise malicious tenant from writing a
>>> Groovy script (or Java program that is inserted on the classpath when
>>> the system is rebooted) that acts as a "trojan horse"? For example, how
>>> can you stop a savvy tenant from adding a program (or, I could even see
>>> hacking the Mini-lang since all it is - is interpreted XML statements)
>>> that monitors (JVM) memory and captures shopping cart objects or
>>> usernames and passwords of the other tenants?
>>> Really, I'd like to endorse multi-tenant implementations. But I am still
>>> left with this one - very significant - security question.
>>> Anyone care to respond? Am I missing something here?
>>> Regards,
>>> Ruth Hoffman
>> --
>> View this message in context: http://ofbiz.135035.n4.nabble.com/Multi-tenant-Security-tp4336437p4337693.html
>> Sent from the OFBiz - User mailing list archive at Nabble.com.

View raw message