[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.
| 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.
| 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
The Guarana MOP  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)
More information about the Pypy-dev