Re: [Zope] Zope application offline - how to apply a license ptotection?
At 14/8/2003 10:40, you wrote:
Our company is developing an application, supposed to be run under dedicated zope server, placed offline in our customers corporate environment and requested via LAN.
What would be the right way to protect this mechanism from hacking, provied that zope is an open-source platform, so any code is hypothetically accessable by the customer and apllication is run completely offline with no intercation with our information system?
The required level of protection is not really high, but we need to be safe from attempts to hack the application by modest programmers at least.
1. use dedicated server with crypted FS (eg., Linux), does not share ANY passwords. 2. does not allow to users gone above specified hierarchy of folders. 3. disable for all other access than "view" all DTML Methods and code-critical DTML documents. etc...
Except 1) the other measures protect against thru-the-web access, but not from local access. Anyone who can read data.fs can see the user passwords, which the standard UserFolder stores without encryption by default, and then can log in as Manager and change anything. And anyone with write permission to the filesystem can create an emergency user, log in as such, and modify all objects inside Zope (the emergency user can do almost anything without restrictions, just can't create new objects). Zope may have a good shield from web attacks but I think it is very vulnerable for local intrusion or sabotage. Gabriel Genellina Softlab SRL
Our company is developing an application, supposed to be run under dedicated zope server, placed offline in our customers corporate environment and requested via LAN.
What would be the right way to protect this mechanism from hacking, provied that zope is an open-source platform, so any code is hypothetically accessable by the customer and apllication is run completely offline with no intercation with our information system?
The required level of protection is not really high, but we need to be safe from attempts to hack the application by modest programmers at least.
1. use dedicated server with crypted FS (eg., Linux), does not share ANY passwords. 2. does not allow to users gone above specified hierarchy of folders. 3. disable for all other access than "view" all DTML Methods and code-critical DTML documents. etc...
Except 1) the other measures protect against thru-the-web access, but not from local access. Anyone who can read data.fs can see the user passwords, which the standard UserFolder stores without encryption by default, and then can log in as Manager and change anything. And anyone with write permission to the filesystem can create an emergency user, log in as such, and modify all objects inside Zope (the emergency user can do almost anything without restrictions, just can't create new objects). Zope may have a good shield from web attacks but I think it is very vulnerable for local intrusion or sabotage.
It is extremely difficult to protect against people with physical or root access to a machine. If I can sit down in front of it, I can get root, and unless you've got an encrypted filesystem, it's game over. And if I'm root on a running machine, probably even an encrypted filesystem won't do any good. Even less-priveledged users can be a threat, due to the possiblity of root exploits. There was a thread a while back where I offered a number of possiblities on protecting a server, and specifically contents of a Zope system, against its own admins. (It started as someone looking for a way to encrypt ZODB contents on the way in.) Look for that. Maybe it'll help. --jcc
On Thu, 2003-08-14 at 13:15, J Cameron Cooper wrote:
It is extremely difficult to protect against people with physical or root access to a machine. If I can sit down in front of it, I can get root
Indeed. Hosting your system on the customer's LAN suggests that your best defense may be a legal agreement. Set up the server to resist most exploits but consider the legal system your primary protection. Dylan
participants (3)
-
Dylan Reinhardt -
Gabriel Genellina -
J Cameron Cooper