Tue Mar 14 17:13:41 PST 2006
The RestrictedPython package contains a slightly modified version of the
compiler package found in the Tools directory of the standard Python
source distribution. It uses this package to convert Python source code
into a tree of objects (an AST) that represent the syntactic structure
of the code. It then edits this tree, and uses the compiler package to
convert this tree into an executable Python code object.
The RestrictionMutator module performs the AST conversion. Functions for
applying restrictions to various sorts of code are contained in the
Compilers module. The Guards, Limits, and Utilites modules contain
dictionaries of replacement builtin functions for, respectively,
security restrictions, resource restrictions, and added functionality.
The PrintCollector module defines a class that is useful for
implementing print redirection. The Eval module provides a helper class
for creating restricted Python expressions.
There are three kind of Python code that can be restricted using the
RestrictedPython package: Expressions, Functions, and Modules. All three
must be provided with global variables containing a read guard function
and a write guard function when executed. If you wish to enable print
statement redirection in a function or module, you must also provide a
print handling class.
An expression cannot contain statements, such as assignments or loops,
but it can still bind variables as a side effect of list comprehensions,
so you must still provide a write guard. An expression can also change
data structures by calling methods such as a list's append() or a
mapping's update(). You should either control or prevent access to these
methods with your read guard, or take care not to expose lists and
dictionaries that should not be modified to restricted code.
Hope this helps
On Sat, 2002-12-14 at 09:03, Aleks Totic wrote:
> I've been evaluating the feasibility of using Python as our
> scripting language for external scripts for Chandler. If this is
> to work, we'd need a bulletproof sandbox.
> The current sandbox standard in Python is rexec. It's
> documentation points out that:
> "While the rexec module is designed to perform as described
> below, it does have a few known vulnerabilities which could be
> exploited by carefully written code."
> Any details/comments on usefullness/security of rexec?
> ZOPE also mentions running sandboxed Python code? What sandbox
> model is it using?
> atotic at osafoundation.org
> John Anderson wrote:
> > -------- Original Message --------
> > Subject: Re: [Dev] risks [was (db policy) transparent persistence]
> > Date: Thu, 28 Nov 2002 09:08:58 +0800
> > From: THoffman at indtech.wa.gov.au
> > To: david at osafoundation.org
> > CC: dev at osafoundation.org
> > I know this will come up often but you guys should have a
> > look at Zope some time (yeah I am sounding like a broken record)
> > It can and does have code in both the Filesystem and in the ZODB.
> > The code in the ZODB in zope is typically scripts run in a restricted
> > environment, so that TTW development is supported. This code
> > cannot open files, sockets etc...
> > Privelidged/Unrestricted code lives in the filesystem.
> > The two work well together, and I don't believe has caused many security
> > issues
> > Zope does have a sophisticated ACL model
> > Rgds
> > Tim Hoffman
> > On Thu, 2002-11-28 at 03:57, David McCusker wrote:
> >> Ricardo M. Reyes wrote:
> >> > I think Object Persistence looks really interesting, but there's
> >> > something that bothers me, and maybe it's already taken care in the
> >> > Persistence implementations.
> >> Another thing to worry about, and perhaps the one that's bothering
> >> Patrick Logan (in another thread I'm getting to on my weblog), is the
> >> option to create spaghetti data with persistent objects because the
> >> freedom doesn't impose any disclipline on developers.
> >> It seems to be human nature to fall apart and lose discipline when
> >> no boundaries are encountered to provide rules about what is good and
> >> what's not, especially when coupled with inability to see the results
> >> of no discipline. Making data more inspectable might help.
> >> But we should also admonish folks to think of their data as having an
> >> actual specified structure to it, even if transparent persistence does
> >> the legwork of storing and fetching. Folks need to think about the
> >> consequences of their choices to avoid creating messes in data.
> >> > I guess that the storage of objects includes the code of the metods.
> >> No, the storage of objects should only include data and none of the
> >> code methods. In this sense, we don't actually store objects when
> >> objects are defined as both code and data.
> >> The code is usually factored out and rejoined to the data when they
> >> are instantiated again from the serialized versions of object data.
> >> There are two things to note about this factoring of code from data
> >> when storing objects this way. First, the result is fragile, in the
> >> sense that versioning the code can cause data to get out of sync.
> >> Second, this factoring is likely the historical consequence of coding
> >> environments that cannot easily store code with data, because having
> >> code link and be operative in the system traditionally has byzantine
> >> complications that are not strictly necessary.
> >> Really dynamic languages like Python could actually store code with
> >> data in a database and have this work without serious hitches. But
> >> it's probably not a good idea, because it's unfriendly to other systems
> >> that want to use the data and are not using Python. And because we
> >> don't have much practical experience troubleshooting typical problems.
> >> > If this is true, then I think it's a huge security risk. If someone
> >> > tampers with the stored representation of an object, it can replace
> >> > an innocent method with something dangerous, and then Chandler would
> >> > execute that trojanized code next time the object is loaded.
> >> Yeah, that would be a big security risk. It's also a bit of a security
> >> risk when the data alone is stored too, because many database systems
> >> were implemented by developers not sufficiently paranoid about finding
> >> corrupt bytes in storage (say, random bit patterns) that will cause
> >> some database systems to crash when using them without checking.
> >> In the past when I've written storage code, I never trusted the bytes
> >> I read from disk (or some other remote location), and always checked
> >> them before using them, so failures were soft exceptions rather than
> >> hard crashes. We might or might not find this level of due diligence
> >> in storage libraries we use that already exist.
> >> If Chandler is successful, and our storage has vulnerabilities that
> >> permit attacks that make us crash, then I'd expect a game of core wars
> >> with folks who want folks to think Chandler is unstable, or otherwise
> >> not as high quality as our goals state.
> >> > Am I wrong? Maybe the code is not stored on disk? or it's encrypted
> >> > somehow?
> >> > > I would really like to hear from someone who used Obj. Persistence
> >> > about this.
> >> No it's not stored on disk, in the database. But it's stored on disk
> >> in the file system where the Python libraries are located. :-/ So the
> >> same attack on code in databases applies in part to attacks on code
> >> in the file system. But folks have more practice coping with file
> >> system attacks.
> >> --David McCusker
DISCLAIMER: This email, including any attachments, is intended only for use
by the addressee(s) and may contain confidential and/or personal information
and may also be the subject of legal privilege. Any personal information
contained in this email is not to be used or disclosed for any purpose other
than the purpose for which you have received it. If you are not the intended
recipient, you must not disclose or use the information contained in it. In
this case, please let me know by return email, delete the message
permanently from your system and destroy any copies. Emails and their
attachments may be interfered with, may contain computer viruses or other
defects and may not be successfully replicated on other systems. All
attachments are opened at the recipient's risk.
More information about the chandler-dev