[Python-Dev] new security doc using object-capabilities

[Brett Cannon]

On 7/23/06, Armin Rigo <arigo at tunes.org> wrote:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060723/229c8fb8/attachment.htm