Mark Seaborn | 14 Sep 2008 23:29

Re: An object-capability subset of Python

zooko <zooko@...> wrote:

> In contrast Guido van Rossum, when I spoke to him at the most recent
> PyCon, emphatically told me "If you think that Python can be made
> into a capability system then you do NOT understand Python!".
> Shortly thereafter he ended our conversation in order to be
> interviewed by a journalist.

Unfortunately that attitude can become self-fulfilling.

I discovered last week that there is a change in Python 3.0 that makes
it harder to make Python safe.

Python 3.0 is removing unbound methods from the language.  In Python
2.x, if you retrieve a function from an attribute of a class, it gets
wrapped by a "unbound method" object which adds a type check.
Currently CapPython depends on this type check being added.

Suppose there are two unrelated classes:

class C(object):
    def __init__(self):
        self._field = "secret"

class D(object):
    def method(self):
        return self._field

If you try to use D.method (an unbound method) on an instance of C it
raises a TypeError:
(Continue reading)

David-Sarah Hopwood | 15 Sep 2008 00:41
Picon

Re: An object-capability subset of Python

Mark Seaborn wrote:
> zooko <zooko@...> wrote:
> 
>> In contrast Guido van Rossum, when I spoke to him at the most recent
>> PyCon, emphatically told me "If you think that Python can be made
>> into a capability system then you do NOT understand Python!".
>> Shortly thereafter he ended our conversation in order to be
>> interviewed by a journalist.
> 
> Unfortunately that attitude can become self-fulfilling.
> 
> I discovered last week that there is a change in Python 3.0 that makes
> it harder to make Python safe.
> 
> Python 3.0 is removing unbound methods from the language.  In Python
> 2.x, if you retrieve a function from an attribute of a class, it gets
> wrapped by a "unbound method" object which adds a type check.
> Currently CapPython depends on this type check being added.
> 
> Suppose there are two unrelated classes:
> 
> class C(object):
>     def __init__(self):
>         self._field = "secret"
> 
> class D(object):
>     def method(self):
>         return self._field
> 
> If you try to use D.method (an unbound method) on an instance of C it
(Continue reading)

Ph.T | 15 Sep 2008 04:29
Picon
Gravatar

Re: An object-capability subset of Python


> . it could be self-fulfilling to assert
> "If you think that Python can be made into a capability system
> then you do NOT understand Python!"

    . I think one can understand the Python language from its name:
a python tackles its problem by getting at first loosely wrapped around it,
working quickly just to grasp the solution,
and when the solution is understood, the fit gets tighter,
and eventually your solution is familiar enough
to constrict it into some compact c code .
. for rapid development, the language has to make Pythonistas feel free,
and at this early part of the development
we want to protect ourselves from them with sandboxing, and journalling;
whereas, e-lang would be a better fit replacing the c code
-- where most of the meat -- and vulnerability -- of the Python is .

    . I recently joined this mailing to help me become familiar with Cap'systems,
and am still unfamiliar enough with security issues
to not feel very confident with anything less than sandboxing with vmwares,
and having operating sytems that can understand their code,
like the way .net/mono can .


On Sun, Sep 14, 2008 at 2:29 PM, Mark Seaborn <mrs-ChQETwBkFSdCgCasaBwmdgC/G2K4zDHf@public.gmane.org> wrote:
zooko <zooko-F7hWHBaSm8MAvxtiuMwx3w@public.gmane.org> wrote:

> In contrast Guido van Rossum, when I spoke to him at the most recent
> PyCon, emphatically told me "If you think that Python can be made
> into a capability system then you do NOT understand Python!".
> Shortly thereafter he ended our conversation in order to be
> interviewed by a journalist.

Unfortunately that attitude can become self-fulfilling.

I discovered last week that there is a change in Python 3.0 that makes
it harder to make Python safe.

Python 3.0 is removing unbound methods from the language.  In Python
2.x, if you retrieve a function from an attribute of a class, it gets
wrapped by a "unbound method" object which adds a type check.
Currently CapPython depends on this type check being added.

Suppose there are two unrelated classes:

class C(object):
   def __init__(self):
       self._field = "secret"

class D(object):
   def method(self):
       return self._field

If you try to use D.method (an unbound method) on an instance of C it
raises a TypeError:

>>> c = C()
>>> D.method(c)
TypeError: unbound method method() must be called with D instance as first argument (got C instance instead)

In Python 3.0 this would return "secret" instead of raising TypeError.

This could be worked around using rewriting but it would make
CapPython more complex and it would be harder to have
CapPython-verified and non-CapPython-verified code interact securely.
I've put some more background on this blog post:
http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html

Mark
_______________________________________________
e-lang mailing list
e-lang-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org
http://www.eros-os.org/mailman/listinfo/e-lang



--
Americium Dream Documents
"(real opportunity starts with real documentation)
http://amerdreamdocs.tripod.com/ http://www.angelfire.com/psy/dr.addn/
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Brett Cannon | 15 Sep 2008 21:06
Favicon
Gravatar

Re: An object-capability subset of Python

On Sun, Sep 14, 2008 at 3:41 PM, David-Sarah Hopwood
<david.hopwood@...> wrote:
> Mark Seaborn wrote:
>> zooko <zooko@...> wrote:
>>
>>> In contrast Guido van Rossum, when I spoke to him at the most recent
>>> PyCon, emphatically told me "If you think that Python can be made
>>> into a capability system then you do NOT understand Python!".
>>> Shortly thereafter he ended our conversation in order to be
>>> interviewed by a journalist.
>>
>> Unfortunately that attitude can become self-fulfilling.
>>
>> I discovered last week that there is a change in Python 3.0 that makes
>> it harder to make Python safe.
>>
>> Python 3.0 is removing unbound methods from the language.  In Python
>> 2.x, if you retrieve a function from an attribute of a class, it gets
>> wrapped by a "unbound method" object which adds a type check.
>> Currently CapPython depends on this type check being added.
>>
>> Suppose there are two unrelated classes:
>>
>> class C(object):
>>     def __init__(self):
>>         self._field = "secret"
>>
>> class D(object):
>>     def method(self):
>>         return self._field
>>
>> If you try to use D.method (an unbound method) on an instance of C it
>> raises a TypeError:
>>
>>>>> c = C()
>>>>> D.method(c)
>> TypeError: unbound method method() must be called with D instance as first argument (got C instance instead)
>>
>> In Python 3.0 this would return "secret" instead of raising TypeError.
>
> That's shocking. They are *deliberately introducing* exactly the
> problem that JavaScript has that makes it so difficult to create
> secure subsets of JavaScript.
>

It must be realized that it is not a goal of the development team to
create a secure subset of the language, so it is not shocking at all.
We removed unbound methods as they were nothing but trouble in the
common case.

But even if we were trying to create a secure subset, no one stepped
forward to point out any security implications of the decision. I
honestly might be the closest thing we have to being a "security
expert" on the core team and that is not saying much.

-Brett
Karp, Alan H | 16 Sep 2008 01:57
Picon
Favicon

Re: An object-capability subset of Python

Brett Cannon wrote:
>
> But even if we were trying to create a secure subset, no one stepped
> forward to point out any security implications of the decision. I
> honestly might be the closest thing we have to being a "security
> expert" on the core team and that is not saying much.
>
Maybe you should forward interesting proposals to this list for comments.  That goes for people working on
other language efforts, too.  Very often a small difference in a language feature makes all the difference
in providing a secure subset.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
Toby Murray | 16 Sep 2008 09:58
Picon
Picon

Re: An object-capability subset of Python

On Mon, 2008-09-15 at 23:57 +0000, Karp, Alan H wrote:
> Brett Cannon wrote:
> >
> > But even if we were trying to create a secure subset, no one stepped
> > forward to point out any security implications of the decision. I
> > honestly might be the closest thing we have to being a "security
> > expert" on the core team and that is not saying much.
> >
> Maybe you should forward interesting proposals to this list for comments.  That goes for people working on
other language efforts, too.  Very often a small difference in a language feature makes all the difference
in providing a secure subset.

Surely it's not the responsibility of general language developers to
ensure the concerns of the "security sideshow" (to quote Linus Torvalds)
are given priority. Rather it should be our responsibility to influence
the design process of languages if we want to ensure that future
revisions will meet our needs (e.g. allow secure ocap subsetting, etc.)

More importantly, we should be producing outputs that prove the value of
our concerns (e.g. the power of a secure ocap subset to build robust
programs) before we ask them to be taken seriously by those who are
trying to juggle the diverse interests of an entire language community.

Cheers

Toby   
Jimmy Wylie Jr. | 16 Sep 2008 10:25
Favicon

E Distributed Programming Clarification

Hi all,

I have been trying to learn and understand distributed programming with E.

My primary concern when I started was how communication between two objects are established securely and how the continued sending of messages remained secure.  From what I understand, these are concerns of CapTP and VatTP. My chief sources of information were Erights.org, ELib, and M. Miller's dissertation.
>From what I've read, the following steps are more or less how the establishment of communication and sending of messages happens.  I just wanted to make sure I was on the right track in my understanding, and I would appreciate any feedback as to whether I am indeed grasping the concepts correctly and any clarification of the details I think I'm missing:
Assuming 3 vats: A, B, C with objects Alice, Bob, and Carol respectively.  The process of establishing communication between Alice and Bob followed by Alice's introduction of Carol to Bob proceeds as follows:

1. Physically hand URI designating Alice to Bob via PGP mail, telephone etc.  With the URI being some form of the YURL as specified in HTTPSY( http://www.waterken.com/dev/YURL/httpsy/). This URI specifies [VatA's ID (a base 32 encoding of the SHA-1 hash of VatA's public key), sequence of hints as to where VatA is,  Swiss# identifying Alice (large random integer)].  Why SHA-1 though?... I seem to remember a Schneier article saying Sha-1 was broken by some Chinese Researchers.
2. VatB receives URI, and looks for VatA using sequence of hints.
3. VatB authenticates correct VatA by verifying that this vat "candidate" knows the private key associated with VatA's public key.  Exactly how is this done? I don't really understand how VatB determines VatA's knowledge of the correct private key.  I know that here: http://www.waterken.com/dev/YURL/httpsy/ it says that servers are authenticated via verification of a constructed certificate chain.  I know httpsy, is related to E's CapTP,  but I remember reading elsewhere, that E rejects the use of certificates in its protocols.
4. Once VatA is authenticated, VatB establishes a connection with VatA as per VatTP, and then sets up a proxy object that represents the local reference to Alice. VatA does the same thing(sets up proxy object to represent reference to Bob).  I know the swiss number is used sometime in this process, but I'm not sure exactly when. 
5. Alice sends Bob a reference to Carol. Reference here is the URI designating Carol and the location of VatC.  The process carried out by VatB in 3, is followed again in search of VatC.
    -- Regarding the sending of messages, my main concern was the result of eavesdropping on packets on a wireless network via a tool like WireShark. So, once the communication link has been established, the messages must be sent securely.  So each TCP packet is encrypted via Triple DES-EDE with Cipher Block Chaining, and even if somehow an eavesdropper managed to decrypt a packet, aren't there still many other layers of encryption in each packet for him to tackle?

Now to put things into practice, I wrote a chat program based on the tutorial by Marc Stiegler at  http://www.skyhunter.com/marcs/echat-writeup.html , but with updated syntax.(It wasn't until later that I realized how similar it was to the chat program towards the end of E in a Walnut minus the persistence features).  As I was testing it, I noticed that on the CS department's small wireless network that most of the time the chat program could establish a connection between my Mac and my friend's PC both running the program. However, sometimes, the operation would timeout and I would get an exception thrown.  I also tried it on the larger campus wide Wifi network.  Unfortunately, the program can never establish a connection.  I attempted to run the program several times, and both situations: where I gave my friend a URI to my program, and he the URI to his.  Strangely enough, when my connection timed out, I received exactly that: a Socket connection timeout exception.  But on my friend's pc, he always receives a NumberFormatException.  Can anyone offer some kind of solution or advice to correct this problem? To make the URI, I am using the makeSturdyRef.temp(obj) to create the sturdy ref, and then sending that to introducer.sturdyToURI(sr).  Then to change that uri into an object, I use introducer.sturdyFromURI(uri).getRcvr().  Are there perhaps, more updated methods I should be using?

Thanks again. Your advice is greatly appreciated,
Jimmy
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Kevin Reid | 16 Sep 2008 13:07
Picon
Gravatar

Re: E Distributed Programming Clarification

On Sep 16, 2008, at 4:25, Jimmy Wylie Jr. wrote:

> I have been trying to learn and understand distributed programming  
> with E. ... My primary concern when I started was how communication  
> between two objects are established securely and how the continued  
> sending of messages remained secure.  ...
> Assuming 3 vats: A, B, C with objects Alice, Bob, and Carol  
> respectively.  The process of establishing communication between  
> Alice and Bob followed by Alice's introduction of Carol to Bob  
> proceeds as follows:
>
> 1. Physically hand URI designating Alice to Bob via PGP mail,  
> telephone etc.  With the URI being some form of the YURL as  
> specified in HTTPSY( http://www.waterken.com/dev/YURL/httpsy/).

Yes, it will be a CapTP URL, which meets the definition of YURL. The  
current syntax is roughly:

   captp://*<hash of public key>:<search path>/<object id>

> Why SHA-1 though?... I seem to remember a Schneier article saying  
> Sha-1 was broken by some Chinese Researchers.

AFAIK, because it looked a lot better when it was chosen; we should  
change this.

(Before I forget to mention this again: MarkM: We need to do something  
about #cryptoHash/0 methods. From where I sit, it seems like a bad  
idea to promote one particular hash algorithm: in general, if we don't  
upgrade it, people will continue to use a hash with known weaknesses;  
if we do upgrade it, there will be incompatibility. I think the  
#cryptoHash should be pulled out into a hash-algorithm object, perhaps  
with a way to import the "current recommendation" (and previous  
algorithms also available, of course).)

> 2. VatB receives URI, and looks for VatA using sequence of hints.

Yes.

> 3. VatB authenticates correct VatA by verifying that this vat  
> "candidate" knows the private key associated with VatA's public  
> key.  Exactly how is this done? I don't really understand how VatB  
> determines VatA's knowledge of the correct private key.

The same way any other public-key-based system works: by requiring  
VatB to decrypt or encrypt something with it. I don't know the  
details, but even certificate-based or trust-network-based systems  
must do this; it is the fundamental step in establishing communication  
with a known party.

> I know that here: http://www.waterken.com/dev/YURL/httpsy/ it says  
> that servers are authenticated via verification of a constructed  
> certificate chain.  I know httpsy, is related to E's CapTP,  but I  
> remember reading elsewhere, that E rejects the use of certificates  
> in its protocols.

This works the way it does, not because the certificates are directly  
useful, but because TLS is defined to work with certificates; HTTPSY  
(and VatTP, in the future) make use of TLS as a well-defined and  
implemented system, not as an ideal-for-capabilities one. (Not that  
there are any flaws that arise from this, but that it does unnecessary  
work.)

> 4. Once VatA is authenticated, VatB establishes a connection with  
> VatA as per VatTP,

No, the authentication is part of the (VatTP) connection setup.

> and then sets up a proxy object that represents the local reference  
> to Alice. VatA does the same thing(sets up proxy object to represent  
> reference to Bob).

Yes; the proxy object is CapTP's job. CapTP handles all adapting- 
object-graph-to-network-stream issues; CapTP abstract messages are  
serialized and sent over a VatTP connection.

> I know the swiss number is used sometime in this process, but I'm  
> not sure exactly when.

Over every CapTP connnection, each side is initially aware of the  
other's NonceLocator object (for that connection). This is how object- 
level communication is bootstrapped.

The swiss number is sent in a lookupSwiss message to VatA's  
NonceLocator, which looks up the number in its SwissTable and returns  
the object.

It basically works like this, except that the parsing happens earlier;  
the rest of this code is in LocatorUnum.

   def [keyFingerprint, searchPath, swissNumber] := parseCapTPURL(url)
   def connection := captp.getOrMakeConnection(keyFingerprint,  
searchPath)
   return connection <- getRemoteNonceLocator() <-  
lookupSwiss(swissNumber)

http://www.erights.org/elib/distrib/captp/lookupSwiss.html
http://www.erights.org/javadoc/net/captp/jcomm/NonceLocator.html

>
> 5. Alice sends Bob a reference to Carol. Reference here is the URI  
> designating Carol and the location of VatC.

No; the data designating Carol does not make a URI. Plain three-vat  
introduction is handled through the NonceLocators; see

http://www.erights.org/elib/distrib/captp/provideFor.html

The connection between VatB and VatC is established in the same way,  
but once made the first message will be acceptFrom rather than  
lookupSwiss.

The reason for this protocol is to ensure that VatB will eventually  
succeed in getting Carol from VatC, even if VatA's provideFor message  
does not get to VatC before VatB's acceptFrom message does.

>     -- Regarding the sending of messages, my main concern was the  
> result of eavesdropping on packets on a wireless network via a tool  
> like WireShark. So, once the communication link has been  
> established, the messages must be sent securely.  So each TCP packet  
> is encrypted via Triple DES-EDE with Cipher Block Chaining, and even  
> if somehow an eavesdropper managed to decrypt a packet, aren't there  
> still many other layers of encryption in each packet for him to  
> tackle?

I can't comment on the cryptographic issues, but we (will) use TLS  
just like every HTTPS connection -- getting the same confidentiality  
and integrity features for the connection. Within the TLS connection,  
there is no additional encryption of messages.

> Now to put things into practice, ... I also tried it on the larger  
> campus wide Wifi network.  Unfortunately, the program can never  
> establish a connection.  I attempted to run the program several  
> times, and both situations: where I gave my friend a URI to my  
> program, and he the URI to his.

I would imagine that the two computers are on separate NAT subnets, or  
that there is a firewall. E as currently implemented has no NAT- 
workaround  support, so you will not be able to *establish* a  
connection from a machine outside some NAT to one inside it. Once the  
connection exists, bidirectional communication will work fine.

> To make the URI, I am using the makeSturdyRef.temp(obj) to create  
> the sturdy ref, and then sending that to  
> introducer.sturdyToURI(sr).  Then to change that uri into an object,  
> I use introducer.sturdyFromURI(uri).getRcvr().  Are there perhaps,  
> more updated methods I should be using?

That's a perfectly fine way to do it.

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Karp, Alan H | 16 Sep 2008 17:12
Picon
Favicon

Re: An object-capability subset of Python

Toby Murray wrote:
>
> Surely it's not the responsibility of general language developers to
> ensure the concerns of the "security sideshow" (to quote Linus
> Torvalds)
> are given priority. Rather it should be our responsibility to influence
> the design process of languages if we want to ensure that future
> revisions will meet our needs (e.g. allow secure ocap subsetting, etc.)
>
We are in violent agreement.  However, if security knowledgeable people don't know what the proposals are
before they are adopted, there will be less chance to have that influence.  I'm proposing that people on
this list who know of pending language changes post a summary here, so that others can comment.  Then it's up
to us to prove the value of our position.  We may find the language designers indifferent between two
versions of a feature, one security enhancing and one security antagonistic.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
Toby Murray | 16 Sep 2008 18:57
Picon
Picon

Re: An object-capability subset of Python

On Tue, 2008-09-16 at 15:12 +0000, Karp, Alan H wrote:
> Toby Murray wrote:
> >
> > Surely it's not the responsibility of general language developers to
> > ensure the concerns of the "security sideshow" (to quote Linus
> > Torvalds)
> > are given priority. Rather it should be our responsibility to influence
> > the design process of languages if we want to ensure that future
> > revisions will meet our needs (e.g. allow secure ocap subsetting, etc.)
> >
> We are in violent agreement.  However, if security knowledgeable people don't know what the proposals are
before they are adopted, there will be less chance to have that influence.  I'm proposing that people on
this list who know of pending language changes post a summary here, so that others can comment.  Then it's up
to us to prove the value of our position.  We may find the language designers indifferent between two
versions of a feature, one security enhancing and one security antagonistic.
> 

Sounds fair enough to me.

Gmane