Hi folks, from the EU side of things there is the plan to organize a security workshop and implement security features within PyPy. I now talked to my IBM research lab contact in Zuerich, and we discussed a few possibilities for such a workshop and the prototype, in particular two possibilities:
- 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. http://www.pmg.lcs.mit.edu/papers/myers-popl99.pdf for some more information in this direction. This is especially interesting for PyPy as - i think - we can probably do better by e.g. also allowing to tag primitive types (JFlow doesn't do that, i think) and allowing things to happen more dynamically at runtime. - sandboxing: allowing to execute (user-supplied/induced) code and preventing it from accessing critical resources, e.g. system IO. 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. I also guess we could also go for a more general metadata-tagging approach which might be useful in more than just the security context. This are just initial ideas - there are arbitrary other possibilities (somewhere care to discuss the "E" lang here?), or are there not? :) 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. Sandboxing and/or e.g. limiting RAM/CPU usage are also interesting to the Python world but probably are a rather orthogonal matter. Regarding the timing of the workshop it seems that something like October this year fits best. It depends on our actual plan and availability/selection of workshop participants if we rather should try to meet in Zuerich or in New York. We can also try to first arrange a discussion with them and then a meeting for presenting the results but that may be a bit much for us (we are not really lacking challenges currently :). 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. best, holger _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
