[Python-Dev] new security doc using object-capabilities (original) (raw)

Brett Cannon brett at python.org
Sun Jul 23 22:00:06 CEST 2006

On 7/23/06, Armin Rigo <arigo at tunes.org> wrote:

Hi David, hi Brett, On Sun, Jul 23, 2006 at 02🔞48AM +0100, David Hopwood wrote: > If I understand correctly, the proposal is that any incompatible changes > to the language would apply only in "sandboxed" interpreters. So there is > no reason why support for these couldn't go into the main branch. That's what I originally thought too, but Brett writes: Implementation Details ======================== An important point to keep in mind when reading about the implementation details for the security model is that these are general changes and are not special to any type of interpreter, sandboxed or otherwise. That means if a change to a built-in type is suggested and it does not involve a proxy, that change is meant Python-wide for all interpreters. So that's why I'm starting to worry that Brett is proposing to change the regular Python language too.

Yes, I am proposing changing some constructors and methods on some built-in types for the regular languages. That's it. No new keywords or major semantic changes and such. If I make changes just for sandboxed interpreters it changes the general approach of the security model by then requiring an identity check to see if the interpreter is sandboxed or not.

However, Brett, you also say somewhere

else that backward compatibility is not an issue. So I'm a bit confused actually...

Since this is my Ph.D. dissertation first and foremost, I am not going to tie my hands in such a way that I have to make too much of a compromise in order for this to work. I obviously don't want to change the feel of Python, but if I have to remove the constructor for code objects to prevent evil bytecode or subclasses() from object to prevent poking around stuff, then so be it. For this project, security is trumpeting backwards-compatibility when the latter is impossible in order to have the former. I will obviously try to minimize it, but something that works at such a basic level of the language is just going to require some changes for it to work.

Also, I hate to sound self-centered, but I should point out somewhere

that PyPy was started by people who no longer wanted to maintain a fork of CPython, and preferred to work on building CPython-like variants automatically. Many of the security features you list would be quite easier to implement and maintain in PyPy than CPython -- also from a security perspective: it is easier to be sure that some protection is complete, and remains complete over time, if it is systematically generated instead of hand-patched in a dozen places.

It doesn't sound self-centered. =) Problem is that my knowledge base is obviously all in CPython so my startup costs are much lower than if I tried this in PyPy. Plus there is the point of embedding this into Firefox (possibly) eventually. Does PyPy support embedding yet at the C level?

-Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060723/229c8fb8/attachment.htm

More information about the Python-Dev mailing list