[pypy-dev] security prototype & workshop plans/ideas

Rodrigo Dias Arruda Senra rodsenra at gpr.com.br
Tue Apr 25 17:53:16 CEST 2006

Some *very* late shameless comments ;o)

[ hpk at trillke.net (holger krekel) ]:
|  Hi folks, 
|  from the EU side of things there is the plan to organize a
|  security workshop and implement security features within PyPy.
|  - data tagging or "label control", or more generally attaching 
|    (security) metainformations to a python object and having those 
|    propagate through the program automatically.  See e.g. 
|  Label control could be used for tagging e.g. user-level input
|  with the "untrusted" label and then protecting certain
|  functions to require trusted input (e.g. database/file
| modifications). Then, there could be explicit untrusted_to_trusted()
|  conversions, turning an untrusted input into a trusted
|  output.  This would allow to concisely localise how 
|  user-supplied/untrusted input is parsed and checked. 
# cut
|  The challenge is to find an interesting mechanism that
|  elegantly enables such approaches - which should be the 
|  topic of our upcoming security prototype and workshop. 
# cut
|  I am posting here on pypy-dev (rather than just to selected pypy
|  developers) because others may be interested, have comments, 
|  suggestions or might think about contributing.  Security is 
|  certainly not the central topic of PyPy but our design should 
|  make it considerably easier to implement strong security features.
|  Hum, and i guess that it's not impossible that the project
|  might for contributors come up with funding for travels at
|  least.  

The Guarana MOP [1] might provide some inspiration, since
Guarana was a reflective meta-object protocol meant to be 

The core idea was to provide a VM-level hook where every access
to an object would test for the presence of a meta-object, using
a pointer in the underlying object representation structure.

If the meta-object was present, access would be intercepted 
and delivered to the meta-object instead.
An image [2, 3] worth a thousand words would show it faster.
The key points were:
 - changing the meta-object bound to some object was
   a negotiation process, where the consent of the installed
   meta-object was required
 - the meta-object controlled all access to the underlying object
 - the meta-object could be a composer delegating decisions to
   a hierarchy of other meta-objects.

I do not know if any of these ideas could/should be used
in Pypy for the challenge proposed by Holger.
Nevertheless, it is harmless to suggest ;o) 

[1] http://citeseer.ist.psu.edu/oliva98reflexive.html

best regards,
Rod Senra

More information about the Pypy-dev mailing list