[e-lang] Re: Python, Twisted, Mont-E

[Mark Miller]

washort at divmod.com wrote:
> Speaking as the Twisted developer who has studied E the most, I would be
> thrilled to incorporate more capability-oriented tools into Twisted, and 
> would be very interested in a secure variant of Python as well. The primary 
> ideas that Twisted has adopted from E are the 'eventually' operator (which 
> inspired Twisted's "Deferred" object: 
> http://www.python.org/pycon/papers/deferex/) and capability-style access to 
> remote objects, as implemented in our Perspective Broker protocol. 

Cool!


> Two of the primary things that Perspective Broker lacks (compared to
> CapTP) are 3-vat transferrable references and promise pipelining. In the
> current codebase I believe adding these to be infeasible, but a new
> version of the protocol is in development, and I have been trying to
> figure out the best way to solve the conflict described at 
> http://www.erights.org/elib/distrib/captp/WormholeOp.html with it. My initial
> prototype of 3-vat introduction allowed near arguments and preserves 
> passability, but does not provide partial ordering. I haven't even tried
> to do promise pipelining yet.

Given that you're going to postpone doing anything like WormholeOp, as we did, 
one of these other issues does indeed need to give. I recommend the choice E 
made here: preserve partial ordering and pipelining, but lose resolution on 
passing. Note that lost ordering will fail unsafe -- causing subtle and 
non-deterministic lost consistency bugs. But lost resolution will fail safe. 
For secure programming especially, you should prefer to fail safe, as losing 
consistency creates opportunities for an attacker that are terribly hard for 
defenders to reason about.


> Another avenue that I have considered is implementing CapTP in Python.
> My attempts to dive into the source for the serialization system left me
> a bit confused, to say the least. :) I am not sure if the difference in
> semantics between E and Python would be too great for this to be
> practical.

Were you looking at JOSS (Java Object Serialization Streams) or Data-E 
serialization? CapTP currently uses JOSS, but will be switching to Data-E. If 
you do decide to implement CapTP, I strongly recommend Data-E serialization 
(using the surface syntax defined by the deBytecodeKit -- see 
<http://www.erights.org/data/serial/jhu-paper/data-e-manual.html>). Most of 
the documentation about Data-E serialization is about reconciling 
serialization with object-granularity mutual suspicion in a principled manner. 
Since you say below that you're interested in moving to object granularity 
security, I think you'll find most of the issues here unavoidable. So please 
let me know what's confusing, and I'll try to clarify.

Another option you should seriously consider is implementing the web-calculus 
before-or-instead-of implementing CapTP. CapTP/Data-E isn't really designed to 
be a good standard for interoperation between cap systems, whereas the 
web-calculus is. I expect and hope to see a web-calculus comm system in E for 
E eventually. CapTP will continue to be E's default, since it more 
transparently extends E's local semantics, but the web-calculus is a better 
way for E to interoperate with other cap systems.

Note that the web-calculus employs another way around the WormholeOp issue: 
forking a reference, by including it as an argument in a message to another 
vat, also gives it a new identity. I don't understand the implications of 
this, but I thought I'd mention it.


> As you might guess, I think that implementing a rich cap-secure network
> protocol will yield the most immediate benefits for Python programmers,
> since that will allow use of traditional isolation techniques (Unix
> processes, host virtualization, etc) for code in different trust domains
> while allowing complex interaction. 

Yes, you can go quite a long ways with process-granularity mutual suspicion. 
And instantiating a virtualized host per process-launch is rapidly becoming an 
affordable way to provide process isolation on legacy OSes.


> Once that's done, though, Mont-E would be a welcome addition. Logix
> might be a useful tool for exploration in that direction:
> http://logix.livelogix.com/
> It is a toolkit for creating languages by defining "operators" 
> (essentially macros),  and it compiles to Python bytecode.
> 
> A cap-secure variant of Python would probably need a new base type. The
> standard one, 'object', allows direct access to all attributes (slots)
> of any object; due to Python's slightly unusual method-calling system,
> one would need to ensure that secure code could never get a reference to
> that type, or that it could never get references to instances of that
> type. Obviously the standard library will require a good deal of taming,
> as well. I believe these obstacles can be overcome, but it's going to 
> take some creativity to balance compatibility with security. 

Unlike some on e-lang, I don't know my way around Python at all. This sounds 
promising, but I would like to inject a caution: Mont-E should be seen 
primarily not as an "addition" but a "subtraction". Don't think of the 
exercise as adding security to Python, but as identifying what subset of 
Python is consistent with cap-security principles, and removing the rest.

Because we started with Sun's Java, which isn't open source, we didn't have 
the option of actually removing the rest, so we instead had to resort to 
taming. Since Python is open source, perhaps Mont-E should actually remove the 
insecurity, rather than just hiding it?

(Btw, my understanding is that the Joe-E project at Berkeley will be starting 
with GCJ/CLASSPATH, so that they can actually remove the insecure parts of 
Java, rather than hiding them as we did.)


> I want to give a big "thank you" to the people who have worked on E; it
> has been a definite inspiration to study the work of people who have such
> insight into and experience with the theory and economics of
> security as well as its practical applications. 

 From all of us, you're welcome!


 > My introduction to
> Python was in the context of a project with similar goals to Electric
> Communities'; I look forward to any collaboration we can achieve.

Likewise!

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM