[ANNOUNCE] The Grand Unification Theory of ZShell Scripts
Hi, I'm pleased to announce the preview version of ZShellScripts v0.1 ZShellScripts is currently distributed under the GNU GPL, but I may change the license if sufficient interest in this product is reported... Download ZShellScripts v0.1 from : http://www.librelogiciel.com/software/ZShellScripts-0.1.tar.gz What is The Grand Unification Theory ??? The Grand Unification Theory : ------------------------------ Why would Zope only support Python Scripts ? Install ZShellScripts instead. This will allow you to add your own languages interpreters, and even define your own language syntax. Here's how : 1 - Create a Shell instance somewhere. Three types of Shell instances are currently provided : * Shell (Python) -- Can execute standard Zope Python Scripts. Code was unashamedly borrowed from Zope 2.5.1, then was re-ordered and factorized, so please report any problem. * Shell (Unix) -- Can execute Unix commands as the user Zope is run as. Variables like context, container, and so on are available as standard environment variables, but will contain the URL to the object instead of its value. This allows your shell script to talk back to Zope using wget for example ! * Shell (Zope) -- Can (*will soon*) execute Zope ZShell commands. This part is currently not working but be sure you'll get it soon !!! Shell (Python) and Shell (Unix) work as expected, as far as I have tested. 2 - Create a "Script (ZShell)" instance, and put the path to your Shell instance on its first line in the usual Unix shell scripts way : #! /path/to/myshell 3 - Put content in your "Script (ZShell)" instance, for example put Python code in it if the shell you use is an instance of "Shell (Python)", or Unix shell commands if it is an instance of "Shell (Unix)", and so on... 4 - Run your "Script (ZShell)" instance as usual, as if it was a standard Zope Python Script for example. Launching your instance, will in fact delegate the code execution to the Shell instance which path you specified on the first line of your "Script (ZShell)" instance. 5 - Enjoy ! 6 - Profit ! (ok, this one comes directly from SlashDot) 7 - Use ShellUnix.py, ShellPython.py, and ShellZope.py as examples to create your own Shell class. ZShellScripts don't need to change. Any comment, bug report or help is **very** welcome. NB : It's only a 0.1 version. Jerome Alet - alet@librelogiciel.com
On Tue, Oct 29, 2002 at 10:07:40PM +0100, Jerome Alet wrote:
I'm pleased to announce the preview version of ZShellScripts v0.1
ZShellScripts is currently distributed under the GNU GPL, but I may change the license if sufficient interest in this product is reported...
I've added more explanations and a screenshot at : http://www.librelogiciel.com/software/ comments and bug reports are welcome. Jerome Alet
On Tue, Oct 29, 2002 at 11:20:37PM +0100, Jerome Alet wrote:
On Tue, Oct 29, 2002 at 10:07:40PM +0100, Jerome Alet wrote:
I'm pleased to announce the preview version of ZShellScripts v0.1
ZShellScripts is currently distributed under the GNU GPL, but I may change the license if sufficient interest in this product is reported...
I've added more explanations and a screenshot at :
http://www.librelogiciel.com/software/
comments and bug reports are welcome.
I just read the code in the x.sh example in your screenshot. Wow. All hail Alet, the greatest ZPervert of them all. - PW (p.s. that was a compliment.) -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"
On Tue, Oct 29, 2002 at 03:46:50PM -0800, Paul Winkler wrote:
On Tue, Oct 29, 2002 at 11:20:37PM +0100, Jerome Alet wrote:
On Tue, Oct 29, 2002 at 10:07:40PM +0100, Jerome Alet wrote:
I'm pleased to announce the preview version of ZShellScripts v0.1
ZShellScripts is currently distributed under the GNU GPL, but I may change the license if sufficient interest in this product is reported...
I've added more explanations and a screenshot at :
I just read the code in the x.sh example in your screenshot.
Wow.
I was sure it was able to please someone :-) I just can't imagine what I'll be able to do with this sort of things... First I planned to do a Perl sample, but I don't know Perl enough. Contribution on this subject is appreciated... Maybe I'll code a C one ;-) I can't hardly wait for the first one who will say : "blah blah blah ... and what about security ? blah blah" I don't care ! The Python shell should be as safe as native Python Scripts. Maybe the other shells are only for zope admins.
All hail Alet, the greatest ZPervert of them all.
(p.s. that was a compliment.)
Thanks for this one, I like it ! Now this really needs testers... Thanks in advance Jerome Alet
I can't see the point of this. The whole point of having TTW python scripts is that they execute in a *restricted* environment, and thus pose no security problem. Your ZShellScripts are a gaping security hole, anyone gaining control of your Zope site (sniffing a password for instance) gains control of your whole machine. Florent Jerome Alet <alet@librelogiciel.com> wrote:
Hi,
I'm pleased to announce the preview version of ZShellScripts v0.1
ZShellScripts is currently distributed under the GNU GPL, but I may change the license if sufficient interest in this product is reported...
Download ZShellScripts v0.1 from :
http://www.librelogiciel.com/software/ZShellScripts-0.1.tar.gz -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
On Thu, Nov 07, 2002 at 04:10:12PM +0000, Florent Guillaume wrote:
I can't see the point of this. The whole point of having TTW python scripts is that they execute in a *restricted* environment, and thus pose no security problem. Your ZShellScripts are a gaping security hole, anyone gaining control of your Zope site (sniffing a password for instance) gains control of your whole machine.
Fine ! You were the first ! see : http://zope.nipltd.com/public/lists/zope-archive.nsf/47ba74c812dbc5dd8025687... especially my 5th paragraph :-) Of course you're wrong. ZShellScripts actually support several languages : - Python : should be exactly as safe as native Zope Python Scripts, since most of the code comes directly from Zope's PythonScript code. - Lisp : runs in a restricted environment, the Lisp interpreter itself is written in Python. - Zope ZShell : runs in a restricted environment (ok this one is not yet fully included) similar to the ZShell standalone product which checks permissions everywhere (or maybe almost everywhere but I haven't received any message concerning security problems in a year and a half) - Unix : runs in a "somewhat" restricted environment : in fact it runs as the user Zope is run as, which shouldn't be root (at least for me it's not root !). You claim of someone gaining full control of my machine is uninformed, at best. OK, the code is not perfect yet, and the 0.2 and CVS versions almost certainely still have security problems, but personnally I can't see the point of people constantly complaining. The fact is that both "Script (ZShell)" objects as well as "Shell (Unix)" objects have permissions which are (or will be) checked. You can expect them to be two times more safe then ;-) As said in a previous message, just forbid people to add or use "Shell (Unix)" objects if you're afraid, and still use the rest if you want, because the execution delegation facility allows some parts of the product to be used independantly than the others. I think you should contribute some code or constructive bug(s) report(s) instead of complaining. Thanks in advance for your cooperation. Jerome Alet
On Thu, 2002-11-07 at 18:44, Jerome Alet wrote:
On Thu, Nov 07, 2002 at 04:10:12PM +0000, Florent Guillaume wrote:
I can't see the point of this. The whole point of having TTW python scripts is that they execute in a *restricted* environment, and thus pose no security problem. Your ZShellScripts are a gaping security hole, anyone gaining control of your Zope site (sniffing a password for instance) gains control of your whole machine.
- Unix : runs in a "somewhat" restricted environment : in fact it runs as the user Zope is run as, which shouldn't be root (at least for me it's not root !). You claim of someone gaining full control of my machine is uninformed, at best.
Ok, Unix is the one that poses security problem. If the others are suitably restricted then ok, I have no beef with them. Basically the problem is that you may allow a remote hacker the use of local exploits instead of restricting him to remote exploits. And you don't need to be root to do damage (remove files or backups or logs, change configuration, kill Zope, all depending on the local machine).
As said in a previous message, just forbid people to add or use "Shell (Unix)" objects if you're afraid, and still use the rest if you want, because the execution delegation facility allows some parts of the product to be used independantly than the others.
That was not my point. One goal of the security restrictions in Zope is that if you're accessing Zope TTW and even if you succeed in becoming Manager (because the site is misconfigured or someone sniffed a Manager password), you can't do any damage outside of the part of the ZODB this Manager has access to. Providing a way to escape the ZODB or restricted code is very dangerous. Consider the whole point of External Methods: they allow access to unrestricted code, but the code has to be written on the filesystem, and not TTW. Mind you, it's probably helpful to some people, but I feel this departs strongly from the basic Zope security model and should be noted prominently. Consider for instance what XXXPythonScript requires:
In order to create or edit XXX Python Scripts, you have to set "ALL_YOUR_BASE_ARE_BELONG_TO" equal to "US".
Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
On Thu, Nov 07, 2002 at 07:08:53PM +0100, Florent Guillaume wrote:
Ok, Unix is the one that poses security problem. If the others are suitably restricted then ok, I have no beef with them.
Basically the problem is that you may allow a remote hacker the use of local exploits instead of restricting him to remote exploits.
agreed. ... snip
Mind you, it's probably helpful to some people, but I feel this departs strongly from the basic Zope security model and should be noted prominently. Consider for instance what XXXPythonScript requires:
In order to create or edit XXX Python Scripts, you have to set "ALL_YOUR_BASE_ARE_BELONG_TO" equal to "US".
good idea. I'll think about such a solution. Jerome Alet
Mind you, it's probably helpful to some people, but I feel this departs strongly from the basic Zope security model and should be noted prominently. Consider for instance what XXXPythonScript requires:
In order to create or edit XXX Python Scripts, you have to set "ALL_YOUR_BASE_ARE_BELONG_TO" equal to "US".
good idea. I'll think about such a solution.
Im really not sure what setting the environment variable gives you. I would prefer just a warning, if you feel one is warranted. Since a user has to have file system access to install the product, they are making a decision to install the software and accept the security considerations of that product (assuming they know what they are). Setting an extra environment variables does nothing to increase security. -- Andy McKay www.agmweb.ca
participants (4)
-
Andy McKay -
Florent Guillaume -
Jerome Alet -
Paul Winkler