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

[Allen Short]

On Sun, 2005-04-17 at 16:43 -0400, Mark Miller wrote:

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

Agreed. If WormholeOp is the best way to solve this problem, I believe
we will soon have the tools to implement it. However, after discussing
this issue with Brian Warner (the author of the new version of PB) and
Zooko, we hit upon a scheme that seems too simple to be correct, but we
can't find the problem with it: A sends a "make yourself available as"
message with a nonce to C, then sends that nonce and C's Swiss number to
B. B uses the nonce when retrieving the reference to C. If the nonce is
not registered yet, B's request is queued. Since the nonce isn't
registered until after previous A->C messages are received, C's vat can
ensure that B can't send any messages to C until then.  As far as I can
tell this doesn't fall into the DoS scenario because there is no need to
block any other messages between vats.

This is very close to how E already does things, from the little I've
read. What am I missing?


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

I'll definitely take a look at that.

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

I don't understand how this gets around the problem either; even if the
two references to an object are not EQ, how does that address the ordering problem?

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

Yes. This is what I'm most interested in pursuing at the moment.


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

The question this raises is "What purpose would Mont-E serve that E does
not?" At the moment, I don't have much hope of porting an appreciable
amount of Python code to a cap-secure language without deep surgery, due
to the pervasive idiomatic usage of direct attribute access. 

> 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?

I assumed that taming would be the natural course to pursue, but on
reflection I agree that this is not a simple task. The fundamental issue
I'm concerned with is how to leverage existing useful Python code when
writing new cap-secure programs. The three approaches that come to mind
are 1) Rewrite Python code into a new language, 2) Run Python code and
new code in the same process and tame the interface, 3) run Python code
and new code in different processes. I imagine different Python projects
will want to pursue different courses.

Allen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.eros-os.org/pipermail/e-lang/attachments/20050418/96319aa3/attachment.bin