[e-lang] Re: Python, Twisted, Mont-E
markm at cs.jhu.edu
Sun Apr 17 16:43:31 EDT 2005
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.
> 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
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:
> 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.
Text by me above is hereby placed in the public domain
More information about the e-lang