Evoque supports
python expressions only. This means that
python statements are already naturally restricted as
when evaluated these will always raise a
SyntaxError.
The problem of restricting execution is thus reduced
to the problem of making the eval python built-in
safe. This is by no means an easy task, but at least with its
more limited scope it is simpler than attempting to
generically restrict or sandbox the python interpreter.
Running in restricted mode will (supposedly)
make it impossible to manipulate tangible resources,
such as files and sockets, from within a template.
Protection of intangible resources,
such as memory and CPU usage, is not (yet) provided (see below).
restricted: bool = False
This is the one domain init parameter that when set
to True will initialize the domain to
run in restricted execution mode.
Setting this to True has therefore the following
consequences:
1. Sets a dummy __builtins__
Sets a dummy __builtins__ empty dict on the
domain-wide globals dict used by eval.
2. No builtins that are deemed unsafe
For every builtin that is not deemed unsafe, will
add a top-level entry to the domain-wide globals dict used by eval.
Python (2.4, 2.5, 2.6, 3.0) __builtins__ currently considered unsafe
are (defined in the list Domain.DISALLOW_BUILTINS):
DISALLOW_BUILTINS = ["_", "__debug__", "__doc__", "__import__", "__name__", "buffer", "callable", "classmethod", "coerce", "compile", "delattr", "dir", "eval", "execfile", "exit", "file", "getattr", "globals", "hasattr", "id", "input", "isinstance", "issubclass", "locals", "object", "open", "quit", "raw_input", "reload", "setattr", "staticmethod", "super", "type", "vars"]
In addition to the above, all subclasses of BaseException
(or, in Python 2.4, of Exception) are considered
potentially unsafe and so are not made available
as entries on the globals dict.
This may seem overly restrictive, but then templating should not
require more than a small subset of python’s
possibilities, for convenience of doing simple progamming tasks
e.g. enumerating over a list.
3. Runtime scan of all expressions
At runtime, all string expressions to be evaluated,
necessarily via restrictedEvaluator[expression],
are first scanned for any disallowed attribute lookups,
and if a string expression matches, a LookupError
will be raised. The restricted_scan pattern will match
any attempt to access any attribute that starts with one of the
following character sequences:
restricted_scan = re.compile(r"|\.\s*".join([ "__", "func_", "f_", "im_", "tb_", "gi_", "throw"]), re.DOTALL)
Note that expression-building trickery will not achieve anything,
as expressions are never evaluated twice i.e. an expression
may build a string but such a string cannot in anyway
be evaluated. To illustrate, consider an expression such as
${legit_obj.__subclasses__()}.
This will fail
because it attempts an attribute lookup that starts with “__”.
Attempting to bypass this by doing something like
${"legit_obj." + "_"*2 + "subclasses" + "_"*2 + "()"}
will simply return the string
"legit_obj.__subclasses__()"
that cannot be re-rendered.
4. No re-evaluation of expressions
Evoque takes every precaution possible to make it impossible to
re-evaluate rendered results in any way.
For example, Evoque templates categorically cannot arbitrarily
set a variable, or initialize a new string-based template.
Furthermore, under restricted mode, builtins such as
eval or getattr are of course
not available.
Is this enough?
Depending on paranoia level, probably not.
Besides more testing to validate that the above effectively
does not allow the template programmer to access and manipulate
any tangible resources, it should still be possible to
bring down the interpreter via DOS maliciousness,
e.g. evaluating an expression for a very large
multiplication to consume all available memory, or to take
a very long time to finish.
Brett Cannon and Eric Wohlstadter, from UBC in Vancouver, have done
some thorough research into the feasibility of more ambitiously
applying a similar but more generalized approach to fully restrict
the python interpreter i.e. all possible expressions and statement
constructs —
they have summarized their work in this inspirational paper:
Controlling Access to Resources Within The Python Interpreter
Nonetheless, further runtime analysis of expressions will be required
to protect against intangible resources such as memory and
CPU usage, and how best to add such
protection is future work that is still to be done.
Thus, for the paranoid, restricted execution mode should for now
best be considered experimental.