Howdy, Ladislav:
You really ought to write up a little explanatory
article for that, how you created a separate execution
context for the untrusted code, why you needed to do a
double bind, etc.
In briefly studying your script, I didn't spot any real
dangers of the untrusted script being able to escape
its secure context and modify the top level context.
If there is that sort of danger what is it?
One principle "danger" involved with executing
arbitrary REBOL code is that an untrusted script might
never finish executing. While not dangerous to your
files or the security of your computer, this could be
an annoying drain of CPU cycles. Of course, the way
security works now, a human operator has to okay
lowering security transitions so that same person can
hit escape if the untrusted script seems to be
endlessly looping. :-) For non-interactive setups, you
could write a file before doing a script and remove it
when the script is done. A watching process may
shutdown and restart the REBOL process if it sees that
the timestamp on the "I'm going to do a script" file is
older than a certain predetermined age.
Moral of the story? There are always inherent risks in
arbitrarily executing random code. Careful
consideration has to be given to the full range of
possibilities. We're very security minded here at
REBOL Tech. as rock solid security is a prerequisite
for successful distributed computing-- and these kinds
of questions are guiding the evolution of REBOL's
security model.
As it stands today, you can build REBOL scripts that
can inspect arbitrary REBOL code, and scripts that can
DO untrusted code. Just turn on all the security and
never try and lower it again.
secure [file throw net throw]
With all the sheilds raised you can DO whatever walks
through the door with out any fear of it resulting in
harm to your system.
Non-interactively (cgi, shell, etc), raise the sheilds,
DO the script, end of program (script gets respawned
later) -- any impact the script could have on your
execution environment will be wiped from memory, so
it's no bother.
-jeff
> If you got here, I have got a problem for you: the present
> code is still dangerous. Could you find why and suggest a
> solution?
>
> {8^D Ladislav
