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

[David Hopwood]

Brett Cannon wrote:
> 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.

I assume that the extent of incompatible changes would be limited as much as
possible. So the only checks would be in operations that are directly affected
by whatever incompatible changes are made. The performance and complexity
costs of this are likely to be small -- or at least should not be assumed to
be large before having hammered out a more detailed design.

Suppose, for the sake of argument, that we introduced private methods and
attributes. If an attribute in an existing standard library class was changed
to be private, then code depending on it would break. But if there were a
notion of a "compatibility private" attribute that acts as private only in a
sandboxed interpreter, then no code running in an unprotected interpreter
would break.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>