S
Sean R. Lynch
I've been playing around with Zope's RestrictedPython, and I think I'm
on the way to making the modifications necessary to create a
capabilities-based restricted execution system. The idea is to strip out
any part of RestrictedPython that's not necessary for doing capabilities
and do all security using just capabilities.
The basic idea behind capabilities is that you don't give any piece of
code you don't trust a reference to something you don't want it to have
access to. You use proxies instead (E calls them "facets").
In order to be able to allow untrusted code to create proxy objects, I
needed to be able to store a reference to the proxied object in a
private attribute.
To create private attributes, I'm using "name mangling," where names
beginning with X_ within a class definition get changed to
_<uuid>_<name>, where the UUID is the same for that class. The UUIDs
don't need to be secure because it's not actually possible to create
your own name starting with an underscore in RestrictedPython; they just
need to be unique across all compiler invocations.
The nice thing about using this name mangling is that it's only done at
compile time and doesn't affect runtime performance. An interesting side
effect is that code defined on a class can access private attributes on
all descendants of that class, but only ones that are defined by other
code on that class, so this isn't a security issue.
I was thinking I needed read-only attributes to be able to avoid
untrusted code's being able to sabotage the revoke method on a proxy
object, but I'm thinking that just keeping around a reference to the
revoke method in the original code may be enough.
Does anyone think I'm going in completely the wrong direction here? Am I
missing anything obvious?
on the way to making the modifications necessary to create a
capabilities-based restricted execution system. The idea is to strip out
any part of RestrictedPython that's not necessary for doing capabilities
and do all security using just capabilities.
The basic idea behind capabilities is that you don't give any piece of
code you don't trust a reference to something you don't want it to have
access to. You use proxies instead (E calls them "facets").
In order to be able to allow untrusted code to create proxy objects, I
needed to be able to store a reference to the proxied object in a
private attribute.
To create private attributes, I'm using "name mangling," where names
beginning with X_ within a class definition get changed to
_<uuid>_<name>, where the UUID is the same for that class. The UUIDs
don't need to be secure because it's not actually possible to create
your own name starting with an underscore in RestrictedPython; they just
need to be unique across all compiler invocations.
The nice thing about using this name mangling is that it's only done at
compile time and doesn't affect runtime performance. An interesting side
effect is that code defined on a class can access private attributes on
all descendants of that class, but only ones that are defined by other
code on that class, so this isn't a security issue.
I was thinking I needed read-only attributes to be able to avoid
untrusted code's being able to sabotage the revoke method on a proxy
object, but I'm thinking that just keeping around a reference to the
revoke method in the original code may be enough.
Does anyone think I'm going in completely the wrong direction here? Am I
missing anything obvious?