On 7/23/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
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.
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.
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
Hi David, hi Brett,
On Sun, Jul 23, 2006 at 02:18: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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
