[Zope] Re: [Crew] External Methods?

[Tres Seaver]

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