Creating a capabilities-based restricted execution system

[Sean R. Lynch]

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 
causing trouble.