Brian Lloyd wrote:
It seems to me that the security problem is that ExternalMethods can get access to "sibling objects" of the object on which they are invoked, right? I mean, if we could make the siblings inaccessible, and acquired properties read-only, then we should be ok, no? Ugh, I don't grok acquisition well enough to tackle that myself, I fear.
Well, it's actually deeper than that. You are correct in saying that DTML alone is not an ASP-killer. Consider the similarities between Zope and, for example, ASP/COM (though the same holds true for practically any other system as well):
Please don't ge me wrong: I _like_ ExternalMethod / Product as a way to extend Zope. My comment is in the context of not (currently) being able to add ExternalMethods to my Zope demesne on starship, given the (quite legitimate) security concerns of the Zopemeister.
ASP lets you use the services provided by (COM) objects, which may be provided by the server or provided independently. I'm sure that MS tries to make the server-provided objects fairly safe, but there is _nothing_ stopping a programmer from writing and installing a COM object with an evil() method that wipes out your C: drive, except the fact that presumably the sysadmin exercises some control over making these independent services available.
I looked at the ExternalMethod source last night a bit: the actual method execution is done via an apply() call, after loading and compiling the code for the function. We might be able to come up with an alternate product which used a carefully tuned rexec() (Bastion? I plead ignorance), operating on Python code stored in the Zbase itself. The particulars of my case are that the control structures of DTML are not quite powerful enough to accomplish my task; of course, strengthening them, even in a "sandbox" model, still leaves open the possibility for buggy/malicious code to do ugly things (like your example below).
The same holds true for Zope (and any other app server out there). Like ASP/COM, External Methods give you the ability to provide more powerful services for use by your application. It also gives you exactly the same problems (though I'm sure that evil() method could be developed in a quarter of the time in Python :)
Basically, with power comes responsibility, and I can't really imagine any system that could _safely_ allow possibly-untrusted people to write (basically) arbitrary code. It's not even really a matter of what services are or are not available to those people. I'm sure that many, many hours and much brain-power went into the design of Java's security mechanisms. Even so, if I were a web site manager I still couldn't let untrusted users write their own arbitrary java code to run in my web or app server.
Even after I had figured out a way to wall off every service I could think of that could possibly be harmful, the user could still probably just do the Java equivalent of:
while 1: pass
Zope DTML goes to a good deal of trouble to minimize these problems in DTML itself, and we would certainly consider any concrete ideas on how to make External Methods safer. Can you give me some examples of other app servers that you feel deal with safety of external services in a better way? I'd be happy to do some looking into how others are dealing with this.
Any Turing machine can do "while 1: pass", so no sufficiently general syntax is "safe" from this attack. Actually, the possibility which seemed most interesting was Doug Wyatt's suggestion of "federating" a set of independent Zbases under one (at least apparently one) server. Then any damage my ExternalMethod did would be to the Zbase would be on my own head, at least. If that server were actually a process running as me, then standard system security procedures should probably be fine. -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com