Creating a capabilities-based restricted execution system
Sean R. Lynch
seanl at chaosring.org
Sun Jan 4 23:39:21 CET 2004
Serge Orlov wrote:
> "John Roth" <newsgroups at jhrothjr.com> wrote in message news:vvg0h93ue63c0b at news.supernews.com...
>>Much of this thread has focused on "capabilities" and the use of
>>proxies to implement capabilities. AFIAC, that's not only putting
>>attention on mechanism before policy, but it's putting attention on
>>mechanism in the wrong place.
> I'm not sure why it should be discussed here since Sean refered
> to E in the first post (http://www.erights.org/), so I think he's
> comfortable with the policy defined by E? I think he has
> missed the part that implementation should help as much as
> it can prevent leaking capabilities from one security domain to
> another. I pointed to that already.
I am comfortable (so far) with the policy defined by E. However, I've
been learning more about that policy as I go, including the necessity of
helping the programmer prevent leaks, which I've started to implement by
making objects completely opaque by default and requiring that classes
list attributes that they want to make public. I have kept my
name-mangling scheme for private attributes. I'm working on making
classes opaque while still allowing code to call methods defined on
superclasses but only on self, not on other objects that happen to
inherit from the same superclass.
>>What I *haven't* seen in this thread is very much consideration of
>>what people want from a security implementation.
> I think Sean is talking about his own implementation. I didn't
> see anywhere he said he's going to write general implementation
> for other people. He said what he wants from his implementation.
I would like my implementation to be as general as possible, but I'm
writing it for my own projects. All this talk of "breaking existing
code" and the like is not particularly relevant to me because, while I'd
like code to look as much like regular Python as possible, it's simply
not possible not to break existing code while helping the programmer
prevent leaks. Making objects opaque by default is going to break a hell
of a lot more code than not having a type() builtin, so I think people
can see why I'm not too concerned about leaving various builtins out.
>>One problem I've been playing around with is: how would you
>>implement something functionally equivalent to the Unix/Linux
>>chroot() facility? The boundaries are that it should not require
>>coding changes to the application that is being restricted, and it
>>should allow any and all Python extension (not C language
>>extension) to operate as coded (at least as long as they don't
>>try to escape the jail!) Oh, yes. It has to work on Windows,
>>so it's not a legitimate response to say: "use chroot()."
This is an interesting problem, but not one I'm trying to solve here.
I'm modifying RestrictedPython to make it possible to use a pure
capabilities-based security model in an application server. The
application server must scale to tens of thousands of security domains,
and I see no reason why the security model can't or shouldn't be
language-based instead of OS-based. There's E for Java, why can't we
make something similar for Python? There is nothing particularly special
about Java that makes it more suitable for E than Python is. Both have
unforgeable references. I've already added object encapsulation. I'm
working on eliminating any static mutable state.
Ultimately, I'd like to have user-level threads, too. I'm considering
either using Stackless for this or doing some mangling of ASTs to make
it easier to use generators as coroutines. Unfortunately, I can't think
of a way for the compiler to tell that you're calling a coroutine from
within a coroutine and therefore needs to output "yield (locals,
resultvarname, func, args, kwargs)" instead of a regular function call
without using some special syntax. Actually, I don't even know if it's
possible to modify the locals dict of a running generator without
More information about the Python-list