Sandboxed (or let's call it restricted) Genshi
Armin Ronacher
I stated working on a sandboxed Genshi branch today, inspired by
cmlenz' post about `logic in templates`_. First of all I want to cover
why sandboxed template engines are important. Say you want to provide
trac + subversion/mercurial/git hosting for a couple of open source
projects without giving the user shell access or the possibility to
upload untrusted plugins (the latter is something people can achieve
by making the plugin folder read only or whatever). Still, users want
to theme their tracs so they start creating Genshi themes. And here
the problem comes up. What if a users adds malicious code to the
template? That can be problematic for the server provider.
In PHP this is not such a big issue because the language as such is
sandboxed thanks to php.ini. In Python we have at least two sandboxed
template engines right now. One of them is django which is sandboxed
because it doesn't support expressions, so no code execution is
possible. The other one is Jinja which does support expressions, but
implemented in a way that the translator intercepts attribute lookups
etc. Also Jinja doesn't provide lambdas or other fancy python things.
A secure Genshi is possible too if we restrict a few things.
The most important thing is that Genshi in restricted mode does not
support <?python code blocks. This allows us to restrict the syntax to
expressions; Genshi even supports disabling those blocks already. The
next important thing is that insecure builtins (eval, file, help,
raw_input etc. disappear from the global scope). And the last part is
that insecure attributes (attributes starting with an underscore) and
special function/method attributes are disabled. Because Genshi
already traverses the AST for code generation, adding this is very
simple.
In the `sandbox branch`_ I implemented all those details and except of
being able to touch the recursion limit (which fortunately can be
caught using try/except) it's impossible to segfault the python
interpreter, gain access to the file system, evaluation functions or
modifying objects passed to the context. (`bug #151`_ is a bit of a
problem because the behavior of objects as targets in iterations is
undefined.) Also the range/xrange function in the context refuses to
create iterables with a length greater than 10.000.
Limitations right now: slows down the execution a bit because of
attribute checking and <?python blocks are not supported. The latter
won't change for obvious reasons.
If you want to give it a try check out that branch and use the
templates with the parameter "restricted=True". The question left now
is, if those changes will find their way into the genshi trunk. While
they are certainly useful for many people that want to use genshi as
template language on mass hosting it also means that this is one more
part that requires maintenance.
Regards,
Armin
.. _logic in templates: http://www.cmlenz.net/blog/2007/07/more-on-logic-i.html
.. _sandbox branch: http://svn.edgewall.org/repos/genshi/branches/experimental/sandboxed/
.. _bug #151: http://genshi.edgewall.org/ticket/151
shday
On Sep 26, 4:01 pm, Armin Ronacher <armin.ronac...@active-4.com>
wrote: