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

[Brett Cannon]

On 9/6/06, Ka-Ping Yee <[EMAIL PROTECTED]
> wrote:
Hi Brett,Here are some comments on your proposal.  Sorry this took so long.I apologize if any of these comments are out of date (but also lookforward to your answers to some of the questions, as they'll help
me understand some more of the details of your proposal).  Thanks!I think they are slightly outdated.  The latest version of the doc is in the bcannon-objcap branch and is named securing_python.txt (
http://svn.python.org/view/python/branches/bcannon-objcap/securing_python.txt
).
> Introduction> ///[...]> Throughout this document several terms are going to be used.  A> "sandboxed interpreter" is one where the built-in namespace is not the
> same as that of an interpreter whose built-ins were unaltered, which> is called an "unprotected interpreter".Is this a definition or an implementation choice?  As in, are youdefining "sandboxed" to mean "with altered built-ins" or just
"restricted in some way", and does the above mean to imply thataltering the built-ins is what triggers other kinds of restrictions(as it did in Python's old restricted execution mode)?

There is no "triggering" of other restrictions.  This is an implementation choice.  "Sandboxed" means "with altered built-ins".

> A "bare interpreter" is one where the built-in namespace has been> stripped down the bare minimum needed to run any form of basic Python> program.  This means that all atomic types (i.e., syntactically
> supported types), ``object``, and the exceptions provided by the> ``exceptions`` module are considered in the built-in namespace.  There> have also been no imports executed in the interpreter.

Is a "bare interpreter" just one example of a sandboxed interpreter,or are all sandboxed interpreters in your design initially bare (i.e."sandboxed" = "bare" + zero or more granted authorities)?
You build up from a bare interpreter by adding in authorities (e.g., providing a wrapped version of open()) to reach the level of security you want.

> The "security domain" is the boundary at which security is cared> about.  For this dicussion, it is the interpreter.It might be clearer to say (if i understand correctly) "Each interpreter
is a separate security domain." Many interpreters can run within a single operating system process,
right?Yes.   Could you say a bit about what sort of concurrency model you
have in mind?None specifically.  Each new interpreter automatically runs in its own Python thread, so they have essentially the same concurrency as using the 'thread' module.

  How would this interact (if at all) with use of theexisting threading functionality?See above. 

> The "powerbox" is the thing that possesses the ultimate power in the> system.  In our case it is the Python process.This could also be the application process, right?If Python is embedded, yes.
> Rationale> ///[...]> For instance, think of an application that supports a plug-in system
> with Python as the language used for writing plug-ins.  You do not> want to have to examine every plug-in you download to make sure that> it does not alter your filesystem if you can help it.  With a proper
> security model and implementation in place this hinderance of having> to examine all code you execute should be alleviated.I'm glad to have this use case set out early in the document, so thereader can keep it in mind as an example while reading about the model.
> Approaches to Security> ///>> There are essentially two types of security: who-I-am> (permissions-based) security and what-I-have (authority-based)
> security.As Mark Miller mentioned in another message, your descriptions of"who-I-am" security and "what-I-have" security make sense, butthey don't correspond to "permission" vs. "authority".  They
correspond to "identity-based" vs. "authority-based" security.Right.  This was fixed the day Mark and Alan Karp made the comment.
> Difficulties in Python for Object-Capabilities> //[...]> Three key requirements for providing a proper perimeter defence is
> private namespaces, immutable shared state across domains, and> unforgeable references.Nice summary.> Problem of No Private Namespace> ===[...]

> The Python language has no such thing as a private namespace.Don't local scopes count as private namespaces?  It seems clearthat they aren't designed with the intention of being exposed,unlike other namespaces in Python.
Sort of.  But you can still get access to them if you have an execution frame and they are not persistent.  Generators are are worse since they store their execution frame with the generator itself, completely exposing the local namespace.
> It also makes providing security at the object level using> object-capabilities non-existent in pure Python code.
I don't think this is necessarily the case.  No Python code i've
ever seen expects to 

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

[Ka-Ping Yee]

Hi Brett,

Here are some comments on your proposal.  Sorry this took so long.
I apologize if any of these comments are out of date (but also look
forward to your answers to some of the questions, as they'll help
me understand some more of the details of your proposal).  Thanks!

> Introduction
> ///
[...]
> Throughout this document several terms are going to be used.  A
> "sandboxed interpreter" is one where the built-in namespace is not the
> same as that of an interpreter whose built-ins were unaltered, which
> is called an "unprotected interpreter".

Is this a definition or an implementation choice?  As in, are you
defining "sandboxed" to mean "with altered built-ins" or just
"restricted in some way", and does the above mean to imply that
altering the built-ins is what triggers other kinds of restrictions
(as it did in Python's old restricted execution mode)?

> A "bare interpreter" is one where the built-in namespace has been
> stripped down the bare minimum needed to run any form of basic Python
> program.  This means that all atomic types (i.e., syntactically
> supported types), ``object``, and the exceptions provided by the
> ``exceptions`` module are considered in the built-in namespace.  There
> have also been no imports executed in the interpreter.

Is a "bare interpreter" just one example of a sandboxed interpreter,
or are all sandboxed interpreters in your design initially bare (i.e.
"sandboxed" = "bare" + zero or more granted authorities)?

> The "security domain" is the boundary at which security is cared
> about.  For this dicussion, it is the interpreter.

It might be clearer to say (if i understand correctly) "Each interpreter
is a separate security domain."

Many interpreters can run within a single operating system process,
right?  Could you say a bit about what sort of concurrency model you
have in mind?  How would this interact (if at all) with use of the
existing threading functionality?

> The "powerbox" is the thing that possesses the ultimate power in the
> system.  In our case it is the Python process.

This could also be the application process, right?

> Rationale
> ///
[...]
> For instance, think of an application that supports a plug-in system
> with Python as the language used for writing plug-ins.  You do not
> want to have to examine every plug-in you download to make sure that
> it does not alter your filesystem if you can help it.  With a proper
> security model and implementation in place this hinderance of having
> to examine all code you execute should be alleviated.

I'm glad to have this use case set out early in the document, so the
reader can keep it in mind as an example while reading about the model.

> Approaches to Security
> ///
>
> There are essentially two types of security: who-I-am
> (permissions-based) security and what-I-have (authority-based)
> security.

As Mark Miller mentioned in another message, your descriptions of
"who-I-am" security and "what-I-have" security make sense, but
they don't correspond to "permission" vs. "authority".  They
correspond to "identity-based" vs. "authority-based" security.

> Difficulties in Python for Object-Capabilities
> //
[...]
> Three key requirements for providing a proper perimeter defence is
> private namespaces, immutable shared state across domains, and
> unforgeable references.

Nice summary.

> Problem of No Private Namespace
> ===
[...]
> The Python language has no such thing as a private namespace.

Don't local scopes count as private namespaces?  It seems clear
that they aren't designed with the intention of being exposed,
unlike other namespaces in Python.

> It also makes providing security at the object level using
> object-capabilities non-existent in pure Python code.

I don't think this is necessarily the case.  No Python code i've
ever seen expects to be able to invade the local scopes of other
functions, so you could use them as private namespaces.  There
are two ways i've seen to invade local scopes:

(a) Use gc.get_referents to get back from a cell object
to its contents.

(b) Compare the cell object to another cell object, thereby
causing __eq__ to be invoked to compare the contents of
the cells.

So you could protect local scopes by prohibiting these or by
simply turning off access to func_closure.  It's clear that hardly
any code depends on these introspection featuresl, so it would be
reasonble to turn them off in a sandboxed interpreter.  (It seems
you would have to turn off some introspection features anyway in
order to have reliable import guards.)

> Problem of Mutable Shared State
> ===
[...]
> Regardless, sharing of state that can be influenced by another
> interpreter is not safe for object-capabilities.

Yup.

> Threat Model
> ///

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

[Greg Ewing]

> Phillip J. Eby wrote:
> 
> > And what about code that needs to pass on a subset of a capability?

With one object == one capability, there is no such
thing as a subset of a capability -- the capabilities
are the atomic units at which you control access. So
you need to make them fine-grained enough to begin
with.

--
Greg
___
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

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

[David Hopwood]

Phillip J. Eby wrote:
> At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote:
>>Phillip J. Eby wrote:
>>
>>>When I say "name checker" I mean the Zope type that allows you to specify
>>>a list of names that are allowed for a given object.  This allowing is not
>>>based on identity or code signing or anything like that.  It's just a list
>>>of attribute names: i.e. a capability mask over an existing object.
>>
>>But this is backwards from what a true object-capability
>>system should be like if it's properly designed. Instead
>>of starting with too-powerful objects and trying to
>>hide some of their powers, the different powers should
>>be separated into different objects in the first place.
> 
> And what about code that needs to pass on a subset of a capability?  You 
> need the ability to create such capability-restricted subsets anyway, no 
> matter how "pure" a system you start with.

That is true, but doing so for every secure object has significant costs.
A simple wrapper is not sufficient, because it would not prevent a wrapped
object from returning a reference to itself, bypassing the wrapper. To solve
this problem you need to use the more complex Membrane pattern, which also
wraps the results of method calls on a wrapped object, for example.

In fact Zope's approach does implement a membrane, but this does not really
dent the argument that Greg Ewing was making. A pure capability system incurs
the complexity and performance costs of wrappers or membranes only in cases
where they are needed, not for every object, and the complexity is only in
user code, not in the system's security kernel.

-- 
David Hopwood <[EMAIL PROTECTED]>


___
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

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

[Phillip J. Eby]

At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > When I say "name checker" I mean the Zope type that allows you to 
> specify a
> > list of names that are allowed for a given object.  This allowing is not
> > based on identity or code signing or anything like that.  It's just a list
> > of attribute names: i.e. a capability mask over an existing object.
>
>But this is backwards from what a true object-capability
>system should be like if it's properly designed. Instead
>of starting with too-powerful objects and trying to
>hide some of their powers, the different powers should
>be separated into different objects in the first place.

And what about code that needs to pass on a subset of a capability?  You 
need the ability to create such capability-restricted subsets anyway, no 
matter how "pure" a system you start with.

And being able to create capability masks for existing objects means you 
don't have to redesign every piece of code ever written for Python to make 
it secure.


>It sounds to me like Zope is using the approach it's
>using because it's having to work with Python as it
>currently is, not because its approach is the best one.


Well, that depends a lot on how you define "best".  Practicality beats 
purity, doesn't it?  ;)

___
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

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

[Greg Ewing]

Phillip J. Eby wrote:

> When I say "name checker" I mean the Zope type that allows you to specify a 
> list of names that are allowed for a given object.  This allowing is not 
> based on identity or code signing or anything like that.  It's just a list 
> of attribute names: i.e. a capability mask over an existing object.

But this is backwards from what a true object-capability
system should be like if it's properly designed. Instead
of starting with too-powerful objects and trying to
hide some of their powers, the different powers should
be separated into different objects in the first place.

It sounds to me like Zope is using the approach it's
using because it's having to work with Python as it
currently is, not because its approach is the best one.

--
Greg
___
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

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

[David Hopwood]

Phillip J. Eby wrote:
> At 11:07 PM 7/23/2006 +0100, David Hopwood wrote:
>> Phillip J. Eby wrote:
>> > At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
>> >
>> >> 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 [trumping] 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.
>> >
>> > Zope 3's sandboxing machinery manages to handle securing these things
>> > without any language changes.  So, declaring it "impossible" to manage
>> > without backward compatibility seems inappropriate, or at least
>> > incorrect.
>>
>> ... if Zope's sandboxing is secure. I haven't done a security review
>> of it, but your argument assumes that it is.
> 
> What argument is that?

You said "Zope 3's sandboxing machinery manages to handle securing these
things without any language changes." This assertion assumes that Zope 3's
sandboxing machinery is secure.

> I'm merely suggesting that coming up with a
> completely new way to secure Python without a serious consideration of
> existing practical prior art (with many years' deployment experience on
> the public internet!) seems ill-advised with respect to achieving
> practical goals.
> 
> Brett's securing_python.txt don't refer to or cite Zope in any way,

This is indeed an omission that should be corrected, in order to explain
why this project is not using Zope or following Zope's approach, and what
the differences are. (I've explained some of them below.)

> but rather relies on broad and unsupported assertions about what can or
> can't be done with Python.  I hope he isn't doing the same in his
> thesis, as this is rather like writing about one's new theory of how to
> have a worldwide ball-kicking contest without making any reference as to
> how one's theory compares with the World Cup.
> 
> I'm not saying Zope is better or worse.  I'm simply saying that in a
> business context, a failure to compare and contrast a proposed "build"
> solution to show how it would be better than a well-established
> available "buy" solution would be called something like "lack of due
> diligence".  I think in the academic context it might be called
> something like "failure to cite", but the general idea is the same,
> i.e., not doing your homework.  :)
> 
> In other words, if the solution being proposed is better than what Zope
> does, the appropriate thing in business is to show the reasons why, and
> the appropriate thing in science is to state a hypothesis regarding the
> differences, and then perform an experiment to either prove or disprove it.

I completely agree with this.

>> In any case, Zope's sandboxing is not capability-based.
> 
> You're right: you haven't done a review of it.  :)

I haven't done a detailed security review. However, I wouldn't have commented
on it without knowing what its basic approach is.

From
:

# When an object is passed to untrusted code, it is wrapped in a security
# proxy unless it is already wrapped. Security proxies mediate all accesses
# to the wrapped object. Operations on security proxies return security
# proxies as well. Security proxies passed from untrusted code to trusted
# code remain wrapped, so untrusted code can't trick trusted code into
# performing operations that the untrusted code could not perform.

Restricting the actions of "trusted" code when called by "untrusted" code
is precisely what a capability system does *not* do. Indeed, capability
systems have no binary distinction between "trusted" and "untrusted" code
(outside the system TCB, which is as small as possible); the only security
distinction between protection domains is in what capabilities they hold.

The main reason why capability systems do not have any such restriction is
that it reduces the system's ability to support fine-grained delegation of
authority. We want to be able to grant an object just the authority it needs
for any particular task. For that to work, code that is otherwise untrusted
must be able to use any capability it is given, even if it is a very powerful
capability, and therefore must be able to call into more-trusted code without
restriction.

To characterise this as "tricking" the more-trusted code is a misconception:
if it is not intended that a particular protection domain should have some
authority, then it should not be given a capability for that authority in
the first place. Capability-based security design emphasises preventing
protection domains from gaining unintended capabilities; it is not about
restricting their use once granted (except t

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

[Phillip J. Eby]

At 12:50 AM 7/24/2006 -0700, Brett Cannon wrote:
>OK, then I need something clarified.  If you read 
>http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies
> 
>, it talks about creating the proxies.  I get they restrict attribute 
>access and wrap all returned objects in proxies themselves (unless they 
>are considered safe).  But to judge whether an attribute should be 
>returned, it checks the security context.

That depends on the checker.  The proxy implementation delegates all access 
decisions to a "checker" object.  Some checkers check permissions, but a 
NamesChecker just checks a statically-defined list of names.


>   It also mentions how access to the security policy must be available so 
> that proper security checks can be done to either grant or deny access.
>
>So what I want to know is if this security context is this global thing 
>that proxies access every time to check whether something is allowed or not.

Proxies don't do that; checkers do.  The default Checker implementation 
doesn't even look at a security context if a name is declared public (i.e., 
it's a NamesChecker).  Look at the zope.security.checker module for details.

IOW, to make it a pure capabilities system, you would only *delete* code, 
not add any, as far as I can tell.


>   Or is it a per-object specification?

Each proxy can have its own checker, but an individual checker instance can 
be shared between proxies.


>   And what is the security domain for Zope proxies; objects, interpreter, 
> running Python program, what?

There are restricted eval and exec operations to run restricted code.

The primary language limitations imposed are the lack of eval/exec by the 
restricted code, and lack of support for raise and 
try/except.  Implementing these would require additional compiler hacking 
to add code to ensure that e.g. tracebacks get wrapped.

___
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

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

[Nick Coghlan]

Brett Cannon wrote:
> On 7/23/06, *Armin Rigo* <[EMAIL PROTECTED] > wrote:
> 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?

Another rationale for basing the work on CPython is that it should be possible 
to implement the resulting security model regardless of the implementation 
language used for the interpreter core (C/Python, Java/Python, C#/Python, 
RPython/Python). If you can figure out how to do it in C, it should be 
feasible to do it in the others.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

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

[Brett Cannon]

On 7/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:When I say "name checker" I mean the Zope type that allows you to specify alist of names that are allowed for a given object.  This allowing is not
based on identity or code signing or anything like that.  It's just a listof attribute names: i.e. a capability mask over an existing object.When you create a proxy using this name mask, that proxy becomes a
capability that allows access to the given names on the underlying object.OK, then using the term "namechecker" through me off.
>I like the fundemental design difference of object-capabilitiesIt's not a difference at all, let alone a fundamental one.  Zope justhappens to allow other kinds of security checking *in addition to*capabilities, if you want them.  However, most of its more basic
encapsulation features are 100% capability based. Meanwhile, if you want to implement an object-capability system, you will
need something that is basically a mask, to allow one piece of code tocreate capabilities that can be given to another.  What you end up with fordoing that is going to look almost exactly like a Zope proxy plus a Zope
name checker. I hate to harp on this point, but there seems to be a trend that when
people have capabilities on their mind, they tend to look at Zope anddismiss it as not being capability-based, when in fact Zope's approach iscapabilities *plus* other things.Well, Jim said that Zope proxies didn't conform to the strict definition of object-capabilities the last time this all came about: 
http://mail.python.org/pipermail/python-dev/2003-March/033884.html and 
http://mail.python.org/pipermail/python-dev/2003-March/033915.html .  He said they *could* be made to be what object-capabilities is defined as, but they were not currently structured that way.  Those comments are one of the reasons I never considered thinking of Zope proxies as a object-capabilities system.
(Of course, most of those "other things" have to do with closing holes like
__subclasses__, while improving performance by still allowing lots ofcommon objects not to be proxied.)OK, then I need something clarified.  If you read 
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies , it talks about creating the proxies.  I get they restrict attribute access and wrap all returned objects in proxies themselves (unless they are considered safe).  But to judge whether an attribute should be returned, it checks the security context.  It also mentions how access to the security policy must be available so that proper security checks can be done to either grant or deny access.
So what I want to know is if this security context is this global thing that proxies access every time to check whether something is allowed or not.  Or is it a per-object specification?  And what is the security domain for Zope proxies; objects, interpreter, running Python program, what?
-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

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

[Phillip J. Eby]

At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:
>On 7/23/06, Phillip J. Eby 
><[EMAIL PROTECTED]> wrote:
>>one proxy plus one namechecker equals one capability.  In other words,
>>you could take the restricted interpreter, the proxy mechanism, and the
>>namechecker and leave most of the rest alone, and you'd have your
>>capability system.  Then you could focus more time and attention on the
>>parts of the problem that Zope *doesn't* solve, instead of reinventing the
>>ones that it already does.
>
>Right, but I am trying to remove the need for a namechecker which makes it 
>an object-capabilities system.

As I said above: a namechecker plus a proxy *equals* an object capability.

When I say "name checker" I mean the Zope type that allows you to specify a 
list of names that are allowed for a given object.  This allowing is not 
based on identity or code signing or anything like that.  It's just a list 
of attribute names: i.e. a capability mask over an existing object.

When you create a proxy using this name mask, that proxy becomes a 
capability that allows access to the given names on the underlying object.


>I like the fundemental design difference of object-capabilities

It's not a difference at all, let alone a fundamental one.  Zope just 
happens to allow other kinds of security checking *in addition to* 
capabilities, if you want them.  However, most of its more basic 
encapsulation features are 100% capability based.

Meanwhile, if you want to implement an object-capability system, you will 
need something that is basically a mask, to allow one piece of code to 
create capabilities that can be given to another.  What you end up with for 
doing that is going to look almost exactly like a Zope proxy plus a Zope 
name checker.

I hate to harp on this point, but there seems to be a trend that when 
people have capabilities on their mind, they tend to look at Zope and 
dismiss it as not being capability-based, when in fact Zope's approach is 
capabilities *plus* other things.

(Of course, most of those "other things" have to do with closing holes like 
__subclasses__, while improving performance by still allowing lots of 
common objects not to be proxied.)

___
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

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

[Brett Cannon]

On 7/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 11:07 PM 7/23/2006 +0100, David Hopwood wrote:>Phillip J. Eby wrote:[snip] 
Brett's securing_python.txt don't refer to or cite Zope in any way, butrather relies on broad and unsupported assertions about what can or can'tbe done with Python.  I hope he isn't doing the same in his thesis, as this
is rather like writing about one's new theory of how to have a worldwideball-kicking contest without making any reference as to how one's theorycompares with the World Cup.The design doc is not meant to be taken as any sort of draft of my thesis.  I did read that link you sent me, Philip, but it was hard to follow.  So I used Google to find another reference that explained it to me much more clearly.  securing_python.txt is meant to explain what I am planning to python-dev so that if someone sees some fatal flaw they can speak up and let me know, not as a thorough comparison of why my approach is better than anyone other one.
I'm not saying Zope is better or worse.  I'm simply saying that in abusiness context, a failure to compare and contrast a proposed "build"
solution to show how it would be better than a well-established available"buy" solution would be called something like "lack of due diligence".  Ithink in the academic context it might be called something like "failure to
cite", but the general idea is the same, i.e., not doing your homework.  :)In other words, if the solution being proposed is better than what Zopedoes, the appropriate thing in business is to show the reasons why, and the
appropriate thing in science is to state a hypothesis regarding thedifferences, and then perform an experiment to either prove or disprove it.I am not going to write out a blow-by-blow comparison right now.  It will come with the thesis.  And I am not expecting my approach or code to be checked in blindly anyway.
>In any case, Zope's sandboxing is not capability-based.You're right: you haven't done a review of it.  :)  If you had, you'd know
that one proxy plus one namechecker equals one capability.  In other words,you could take the restricted interpreter, the proxy mechanism, and thenamechecker and leave most of the rest alone, and you'd have your
capability system.  Then you could focus more time and attention on theparts of the problem that Zope *doesn't* solve, instead of reinventing theones that it already does.Right, but I am trying to remove the need for a namechecker which makes it an object-capabilities system.
Now, if Brett believes that changing the Python language is a *better* way
to implement capabilities than using proxies to implement them, thengreat.  His paper should explain why, and (presumably) include experimentalresults to show that they're either better or worse than Zope's approach
based on some criteria.  The same information is relevant to Python-Dev asto what is an appropriate approach to support sandboxing in CPython.  Whatare the advantages of a built-in approach versus an add-on approach?  Are
there interpreter facilities that could be added to shore up any awkwardaspects of Zope's approach?  (Whatever those might be.)I think people are starting to lose sight of the purpose of the doc I wrote.  It was to explain what I was doing for people to see if there was any fatal flaw and to keep people updated on what I am planning on doing.  It is not meant to convince anyone that my way is the best way yet.  I am not even going to attempt that until I have working code.
For example, one part of Zope's approach uses a custom compiler and custom
builtins in order to redefine how attribute access works in certaincases.  Could these customizations be replaced with options built into thePython compiler and interpreter?  What improvements would that result in?
Part of my point is to help alleviate the need for custom anything.
Simply handwaving all of these questions away, however, with broadassertions of superiority and without even attempting to compare the newwork to Zope's existing work is really not acceptable for academia ORPython development.
For the record: I have no personal interest in Zope's security system.  Ididn't develop it and haven't had the need to use it, myself.  I oncereviewed some of the code and offered some minor suggestions, mainly
regarding performance improvement.  My only axe to grind in this matter iswhat I've already stated: I think it would be crazy (in the "monumentalwaste of resources" sense) to consider putting *any* sandboxing system into
CPython without tapping the Zope team's experiences.  For example: havingimplemented such a system, what compiler or interpreter changes would'vemade the job easier?Meanwhile, what Brett does or doesn't put in his thesis is between him and
his advisor, but what gets put into Python shouldn't be based on ignoringthe existing field experience and state of the art.There is no ignoring of anything.  I understand their basic approach and I want to try another one.  I like the fundementa

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

[Phillip J. Eby]

At 11:07 PM 7/23/2006 +0100, David Hopwood wrote:
>Phillip J. Eby wrote:
> > At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
> >
> >>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 [trumping] 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.
> >
> > Zope 3's sandboxing machinery manages to handle securing these things
> > without any language changes.  So, declaring it "impossible" to manage
> > without backward compatibility seems inappropriate, or at least
> > incorrect.
>
>... if Zope's sandboxing is secure. I haven't done a security review of it,
>but your argument assumes that it is.

What argument is that?  I'm merely suggesting that coming up with a 
completely new way to secure Python without a serious consideration of 
existing practical prior art (with many years' deployment experience on the 
public internet!) seems ill-advised with respect to achieving practical goals.

Brett's securing_python.txt don't refer to or cite Zope in any way, but 
rather relies on broad and unsupported assertions about what can or can't 
be done with Python.  I hope he isn't doing the same in his thesis, as this 
is rather like writing about one's new theory of how to have a worldwide 
ball-kicking contest without making any reference as to how one's theory 
compares with the World Cup.

I'm not saying Zope is better or worse.  I'm simply saying that in a 
business context, a failure to compare and contrast a proposed "build" 
solution to show how it would be better than a well-established available 
"buy" solution would be called something like "lack of due diligence".  I 
think in the academic context it might be called something like "failure to 
cite", but the general idea is the same, i.e., not doing your homework.  :)

In other words, if the solution being proposed is better than what Zope 
does, the appropriate thing in business is to show the reasons why, and the 
appropriate thing in science is to state a hypothesis regarding the 
differences, and then perform an experiment to either prove or disprove it.


>In any case, Zope's sandboxing is not capability-based.

You're right: you haven't done a review of it.  :)  If you had, you'd know 
that one proxy plus one namechecker equals one capability.  In other words, 
you could take the restricted interpreter, the proxy mechanism, and the 
namechecker and leave most of the rest alone, and you'd have your 
capability system.  Then you could focus more time and attention on the 
parts of the problem that Zope *doesn't* solve, instead of reinventing the 
ones that it already does.

Now, if Brett believes that changing the Python language is a *better* way 
to implement capabilities than using proxies to implement them, then 
great.  His paper should explain why, and (presumably) include experimental 
results to show that they're either better or worse than Zope's approach 
based on some criteria.  The same information is relevant to Python-Dev as 
to what is an appropriate approach to support sandboxing in CPython.  What 
are the advantages of a built-in approach versus an add-on approach?  Are 
there interpreter facilities that could be added to shore up any awkward 
aspects of Zope's approach?  (Whatever those might be.)

For example, one part of Zope's approach uses a custom compiler and custom 
builtins in order to redefine how attribute access works in certain 
cases.  Could these customizations be replaced with options built into the 
Python compiler and interpreter?  What improvements would that result in?

Simply handwaving all of these questions away, however, with broad 
assertions of superiority and without even attempting to compare the new 
work to Zope's existing work is really not acceptable for academia OR 
Python development.

For the record: I have no personal interest in Zope's security system.  I 
didn't develop it and haven't had the need to use it, myself.  I once 
reviewed some of the code and offered some minor suggestions, mainly 
regarding performance improvement.  My only axe to grind in this matter is 
what I've already stated: I think it would be crazy (in the "monumental 
waste of resources" sense) to consider putting *any* sandboxing system into 
CPython without tapping the Zope team's experiences.  For example: having 
implemented such a system, what compiler or interpreter changes would've 
made the job easier?

Meanwhile, what Brett does or doesn't put in his thesis is between him and 
his advisor, but what gets put into Python shouldn't be based on ignoring 
the existing field experience and state of the art.

__

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

[David Hopwood]

Brett Cannon wrote:
> On 7/23/06, Armin Rigo <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>


___
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

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

[David Hopwood]

Phillip J. Eby wrote:
> At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
> 
>>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 [trumping] 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.
> 
> Zope 3's sandboxing machinery manages to handle securing these things 
> without any language changes.  So, declaring it "impossible" to manage 
> without backward compatibility seems inappropriate, or at least 
> incorrect.

... if Zope's sandboxing is secure. I haven't done a security review of it,
but your argument assumes that it is.

In any case, Zope's sandboxing is not capability-based.

-- 
David Hopwood <[EMAIL PROTECTED]>


___
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

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

[Phillip J. Eby]

At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
>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.

Zope 3's sandboxing machinery manages to handle securing these things 
without any language changes.  So, declaring it "impossible" to manage 
without backward compatibility seems inappropriate, or at least 
incorrect.  But perhaps there is something I'm missing?

___
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

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

[Brett Cannon]

On 7/23/06, Armin Rigo <[EMAIL PROTECTED]> 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 DetailsAn important point to keep in mind when reading about the
implementation details for the security model is that these aregeneral 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 meantPython-wide for *all* interpreters.So that's why I'm starting to worry that Brett is proposing to changethe 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 somewhereelse 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 somewherethat PyPy was started by people who no longer wanted to maintain a fork
of CPython, and preferred to work on building CPython-like variantsautomatically.  Many of the security features you list would be quiteeasier to implement and maintain in PyPy than CPython -- also from asecurity perspective: it is easier to be sure that some protection is
complete, and remains complete over time, if it is systematicallygenerated 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

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

[Armin Rigo]

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.  However, Brett, you also say somewhere
else that backward compatibility is not an issue.  So I'm a bit confused
actually...

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.


A bientot,

Armin
___
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

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

[Armin Rigo]

Hi Brett,

On Sat, Jul 22, 2006 at 10:33:19AM -0700, Brett Cannon wrote:
> Thanks for the link, Armin.  Since you guys don't have the import
> restrictions the CPython version would have and just have different coding
> needs for RPython obviously I can't just do a blind copy.  But I will
> definitely take a look as I develop.  Maybe you guys can even help to lower
> the duplication if it makes sense for you.

Yes, it should be possible to abstract the common logic in some way,
using some kind of interface for all OS inspection and 'sys.modules'
manipulations.

> BTW, do you guys happen to have extra tests from import?

Yes, there is
http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/test/test_import.py

which will also need a bit of rewriting, but that should be
straightforward.


A bientot,

Armin
___
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

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

[David Hopwood]

Armin Rigo wrote:
> Re-hi,
> 
> On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:
> 
>>http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log.
> 
> I'm not sure I understand what you propose to fix holes like
> constructors and __subclasses__: it seems that you want to remove them
> altogether (and e.g. make factory functions instead).  That would
> completely break all programs, right?  I mean, there is no way such
> changes would go into mainstream CPython.

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.

Of course we want to minimize the changes that will need to be made to
programs and libraries to make them work in a sandboxed interpreter, but
not at the expense of security. Some incompatible changes will be necessary.

-- 
David Hopwood <[EMAIL PROTECTED]>


___
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

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

[Greg Ewing]

Armin Rigo wrote:

> I'm not sure I understand what you propose to fix holes like
> constructors and __subclasses__: it seems that you want to remove them
> altogether (and e.g. make factory functions instead).  That would
> completely break all programs, right?  I mean, there is no way such
> changes would go into mainstream CPython.

How much code is actually out there that uses __subclasses__?
It seems like a fairly esoteric corner of the language to me.

In any case, I think this approach should certainly be tried,
and if it works out, considered for Py3k.

--
Greg
___
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

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

[Brett Cannon]

On 7/22/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
Hi Brett,On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:> I also plan to rewrite the import machinery in pure Python.
http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/importing.pyThanks for the link, Armin.  Since you guys don't have the import restrictions the CPython version would have and just have different coding needs for RPython obviously I can't just do a blind copy.  But I will definitely take a look as I develop.  Maybe you guys can even help to lower the duplication if it makes sense for you.
BTW, do you guys happen to have extra tests from import?-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

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

[Brett Cannon]

On 7/22/06, Armin Rigo <[EMAIL PROTECTED]> wrote:> Re-hi,> > On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:> > 
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log.> > I'm not sure I understand what you propose to fix holes like> constructors and __subclasses__: it seems that you want to remove them
> altogether (and e.g. make factory functions instead).  That would> completely break all programs, right?Not altogether, just constructors on select types who are considered dangerous from a security standpoint.  The breakage won't be horrible, but it will be there for advanced Python code.
I will try to make the wording more clear when I get back to work on Tuesday.>  I mean, there is no way such> changes would go into mainstream CPython.If this has to wait until Py3k then so be it.
>  Or do you propose to maintain> a CPython branch manually for the foreseeable future?  (From experience> this is a bad idea...)> Yeah, not my idea of fun either, but since this is a long term project, I will at least need to for the foreseeable future.
-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

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

[Armin Rigo]

Re-hi,

On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:
> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log.

I'm not sure I understand what you propose to fix holes like
constructors and __subclasses__: it seems that you want to remove them
altogether (and e.g. make factory functions instead).  That would
completely break all programs, right?  I mean, there is no way such
changes would go into mainstream CPython.  Or do you propose to maintain
a CPython branch manually for the foreseeable future?  (From experience
this is a bad idea...)


A bientot,

Armin
___
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

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

[Armin Rigo]

Hi Brett,

On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:
> I also plan to rewrite the import machinery in pure Python.

http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/importing.py


A bientot,

Armin
___
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

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

[Nick Coghlan]

Brett Cannon wrote:
> Extensible file type handling
> -
> If the file type handlers are stored in normal Python data
> structures as
> described above, it becomes feasible to make the import system
> extensible to
> different file types as well as to different file locations.
> 
> 
> Yep.  Although I am more interested in restricting than broadening the 
> file types.

Either way you'd be mutating the list of recognised file types :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

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

[Lawrence Oluyede]

> Should be faster than an IBAC model since certain calls will not need to
> check the identity of the caller every time.
>
> But I am not worrying about performance, I am worrying about correctness, so
> I did not try to make any performance claims.

Got that.

> Nope.  Have not started worrying about that yet.  Just trying to get the
> basic model laid out.

Ok sorry to have bothered

> That is the point.  It is not that the sandbox needs to know it, its that it
> needs to be hidden from the sandbox.

So I think that's a "simple" step during the importing step.

> I have not looked at it.  I am also not trying to build an RPC system *and*
> a security model for Python.  That is just too much work right now.

Ok sorry :-)

> Thanks, Lawrence.

Thank you!

-- 
Lawrence
http://www.oluyede.org/blog
___
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

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

[Terry Reedy]

"Lawrence Oluyede" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> - I know what you meant to say but the paragraph about pythonicness
> and the security model seems a little "fuzzy" to me.

I agree that this paragraph is weak and recommend that it be rewritten.  In 
particular, I think the 'pythonic*' words should go, especially if you 
expect this document to be read by anyone other than dedicated pythonistas. 
I would start with something like

"It is my goal that my thesis work be incorporated in some future version 
of the Python distribution.  This has two constraints.  First, changes to 
the core must not slow down normal operation.  Second, visible changes must 
not violate the spirit and style of Python that make it a distinctive 
language."

This alludes to the fact that your proposal discusses two highly 
overlapping yet separate projects: write a thesis that gains you a PhD 
degree; and produce an accepted patch set that give Python a useful 
security capability it does not now have.  They have to be thought of as 
somewhat separate because you have two sets of 'overseers' and approvers: 
your thesis advisor and committee for the first; and Guido and other Python 
developers for the second.

I think your thesis should currently be your first priority.  Your current 
paragraph implied to me that you would not follow a promising line of 
research if you could not see how to make it 'pythonic'.  If I were on your 
thesis committee, I think that would bother me ;-).

In any case, I wish you the best with a double project that is obviously 
not a 'gimme'.

Terry Jan Reedy (PhD, though not on any thesis committees)



___
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

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

[Brett Cannon]

On 7/20/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:>>http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
>> . How do you plan to handle CPU-hogs? Stuff like execution of a>> gigantic integer multiplication.>>> I don't.  =)  Protecting the CPU is damn hard to do in any form of
> portable fashion.  And even getting it to work on an OS you do know> the details of leads to probably an interrupt  implementation and> that doesn't sound fun.I think the trick used by the safe_eval recipe (a separate thread which
interrupts the script through thread.interrupt_main()) shows that, in mostcases, it's possible to make sure that an embedded script does not take toolong to execute. Do you agree that this usage case ("allow me to timeout an
embedded script") is something which would be a very good start in the rightdirection?Probably.  I just don't feel like worrying about it right now.  =) 
Now, I wonder, in a restricted execution environment such as that depictedin your document, how many different ways are there to make the Pythoninterpreter enter a long calcolation loop which does not release the GIL? I
can think of bignum*bignum, bignum**bignum or similar mathematicaloperations, but there are really a few. If we could make those release theGIL (or poll some kind of watchdog used to abort them, pretty much like they
normally poll CTRL+C), then the same trick used by the recipe could be used.Well, any work that does most of its calculation within C code and that does not touch base with the interpreter on a semi-regular basis would need to relesae the GIL.
-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

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

[Giovanni Bajo]

Brett Cannon wrote:

>>
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
>> .
>>
>> How do you plan to handle CPU-hogs? Stuff like execution of a
>> gigantic integer multiplication.
>
>
> I don't.  =)  Protecting the CPU is damn hard to do in any form of
> portable fashion.  And even getting it to work on an OS you do know
> the details of leads to probably an interrupt  implementation and
> that doesn't sound fun.

I think the trick used by the safe_eval recipe (a separate thread which
interrupts the script through thread.interrupt_main()) shows that, in most
cases, it's possible to make sure that an embedded script does not take too
long to execute. Do you agree that this usage case ("allow me to timeout an
embedded script") is something which would be a very good start in the right
direction?

Now, I wonder, in a restricted execution environment such as that depicted
in your document, how many different ways are there to make the Python
interpreter enter a long calcolation loop which does not release the GIL? I
can think of bignum*bignum, bignum**bignum or similar mathematical
operations, but there are really a few. If we could make those release the
GIL (or poll some kind of watchdog used to abort them, pretty much like they
normally poll CTRL+C), then the same trick used by the recipe could be used.
-- 
Giovanni Bajo

___
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

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

[Brett Cannon]

On 7/20/06, Lawrence Oluyede <[EMAIL PROTECTED]> wrote:
That's great. I just read your draft but I have little comments to dobut before let me say that I liked the idea to borrow concepts from E.I've crossed the E's path in the beginning of this year and I found it
a pot of really nice ideas (for promises and capabilities). Here aremy comments about the draft:- it's not really clear to me what the "powerbox" is. I think I gotthe concept of "super process" but maybe it's to be clarified, isn't
it? It become clear in the "threat model" paragraphThe powerbox is the thing that gives your security domains their initial abilities.  The OS gives the process its abilities, but it does not directly work with the interpreter.  Since the process does, though, it is considered the powerbox and farms out abilities that it has been given by the OS.
I have tried to clarify the definition at the start of the doc.- I hope no Rubystas will read the "Problem of No Private Namespace"
section because they have private/protected keywords to enforce thisstuff :-) Writing proxies in C will slow down the dev process (altoughwill speed up the performance maybe) but in a far future someone will
come up with an alternative closer to the Python levelMaybe.  As I said in the doc, any changes must be Pythonic and adding private namespaces right now wouldn't be without much more thought and work.
And if Ruby ends up with this security model but more thoroughly, more power to them.  Their language is different in the right ways to support it.As for coding in C, thems the breaks.  I plan in adding stuff to the stdlib for the common case.  I might eventually think of a good, generic proxy object that could be used, but as of right now I am not worrying about that since it would be icing on the cake.
- Can you write down a simple example of what you mean with "changing
something of the built-in objects"? (in "Problem of mutable sharedstate")Done. 
- What about the performance issues of the capabilities model overall?Should be faster than an IBAC model since certain calls will not need to check the identity of the caller every time.But I am not worrying about performance, I am worrying about correctness, so I did not try to make any performance claims.
- I know what you meant to say but the paragraph about pythonicnessand the security model seems a little "fuzzy" to me. Which are the
boundaries of the allowed changes for the security stuff?Being "pythonic" is a fuzzy term in itself and Guido is the only person who can make definitive claims over what is and is not Pythonic.  As I have said, this doc was mostly written with python-dev in mind since they are the ones I have to convince to let this into the core and they all know the term.
But I have tacked in a sentence on what the term means.- You don't say anything about networking and networked resources in
the list of the standard sandboxed interpreterNope.  Have not started worrying about that yet.  Just trying to get the basic model laid out. 
- Suppose we have a .py module. Based on your security model we canimport it, right? When imported it generates a .pyc file. The secondtime we import it what happens? .pyc is ignored? import is not allowedat all? We can't rely on the name of the 
file.pyc because an attackerwho knows the file.py is secure and the second import is done againstfile.pyc can replace the "secure" file.pyc with an implementation notsecure and can do some kind of harm to the sandbox
It will be ignored.  But I am hoping that through rewriting the import machinery more control over generating .pyc files can be had (see Skip Montanaro's PEP on this; forget the number).  This is why exact details were left out of the implementation details.  I just wanted people understand the approach to everything, not the concrete details of how it will be coded up.
- About "Filesystem information". Does the sandboxed interpreter need
to know all that information about file paths, files and so on? Can'twe reset those attributes to something arbitrary?That is the point.  It is not that the sandbox needs to know it, its that it needs to be hidden from the sandbox.
- About sys module: I think the best way is to have a purged fake sysmodule with only the stuff you need. pypy has the concept of faked
modules too (altough for a different reason)OK. - About networking: what do you think about the E's model of really
safe networking, protected remotable objects and safe RPC? Is thatmodel applicable to Python's in some way? We can't use the E's modelas a whole (ask people to generate a safe key and send it by email isunfeasible)
I have not looked at it.  I am also not trying to build an RPC system *and* a security model for Python.  That is just too much work right now. 
- is the protected memory model a some kind of memory monitor system?Basically.  It just keeps a size_t on the memory cap and another on memory usage, and when memory is requested it makes sure that it won't go over the cap.  And wh

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

[Brett Cannon]

On 7/20/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
For code objects, their construction is already commonly written as"compile(source)".Right, but some people like to construct directly from bytecode. 
For type objects, the constructor doesn't let you do anything you can'talready do with a class statement. It doesn't need securing.I figured as much, but when I was making the list I was not sure and didn't want to stop my writing momentum to check.
For rewriting import.c in Python, the PEP 302 compliant import system API in
pkgutil would be a good starting point.Yep.  Plan on looking at all of the various modules in the stdlib that assist with importing, package PEP (I think there is one), and PEP 302.
Your doc also asks about the imp.get_suffixes() list, and wonder where to setit from Python.As far as I am aware, you can't. get_suffixes() is built from_PyImport_FileTab, which is a C array. A switch statement is used to get from
the file table entries to the appropriate handler functions.Ah, OK. 
Quoting from the suggestions I put to the Py3k list:Use smarter data structures---Currently, the individual handlers to load a fully identified module areexposed to Python code in a way that reflects the C-style data structures used
in the current implementation.Simply switching to more powerful data structures for the file type handlers(i.e. use a PyTuple for filedescr values, a PyList for _PyImport_FileTab, anda PyDict instead of a switch statement to go from filedescr values to module
loading/initialisation functions) and manipulating them all as normal Pythonobjects could make the code in import.c much easier to follow.Yep.  I just kind of glanced at the rest of your suggestions, Nick, since I assumed a lot of it would change (or could be changed) if import was redone in as much Python as possible.
Extensible file type handling-If the file type handlers are stored in normal Python data structures as
described above, it becomes feasible to make the import system extensible todifferent file types as well as to different file locations.Yep.  Although I am more interested in restricting than broadening the file types. 
This could be handled on a per-package basis, e.g. via a __file_types__special attribute in packages.
Maybe.  I don't want to get into introducing new abilities to start, though.-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

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

[Brett Cannon]

On 7/20/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:>> The new doc is named securing_python.txt and>> can be>> found through the svn web interface at>>
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log.How do you plan to handle CPU-hogs? Stuff like execution of a giganticinteger multiplication.
I don't.  =)  Protecting the CPU is damn hard to do in any form of portable fashion.  And even getting it to work on an OS you do know the details of leads to probably an interrupt  implementation and that doesn't sound fun. 
-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

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

[Nick Coghlan]

For code objects, their construction is already commonly written as 
"compile(source)".

For type objects, the constructor doesn't let you do anything you can't 
already do with a class statement. It doesn't need securing.

For rewriting import.c in Python, the PEP 302 compliant import system API in 
pkgutil would be a good starting point.

Your doc also asks about the imp.get_suffixes() list, and wonder where to set 
it from Python.

As far as I am aware, you can't. get_suffixes() is built from 
_PyImport_FileTab, which is a C array. A switch statement is used to get from 
the file table entries to the appropriate handler functions.

Quoting from the suggestions I put to the Py3k list:

Use smarter data structures
---
Currently, the individual handlers to load a fully identified module are
exposed to Python code in a way that reflects the C-style data structures used
in the current implementation.

Simply switching to more powerful data structures for the file type handlers
(i.e. use a PyTuple for filedescr values, a PyList for _PyImport_FileTab, and
a PyDict instead of a switch statement to go from filedescr values to module
loading/initialisation functions) and manipulating them all as normal Python
objects could make the code in import.c much easier to follow.

Extensible file type handling
-
If the file type handlers are stored in normal Python data structures as
described above, it becomes feasible to make the import system extensible to
different file types as well as to different file locations.

This could be handled on a per-package basis, e.g. via a __file_types__
special attribute in packages.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

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

[Giovanni Bajo]

Nick Maclaren wrote:

>> This recipe for safe_eval:
>> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496746
>> which is otherwise very cute, does not handle this case as well: it
>> tries to catch and interrupt long-running operations through a
>> secondary thread, but fails on a single long operation because the
>> GIL is not released and the alarm thread does not get its chance to
>> run.
>
> Grin :-)
>
> You have put your finger on the Great Myth of such virtualisations,
> which applies to the system-level ones and even to the hardware-level
> ones.  In practice, there is always some request that a sandbox can
> make to the hypervisor that can lock out or otherwise affect other
> sandboxes.
>
> The key is, of course, to admit that and to specify what is and is
> not properly virtualised, so that the consequences can at least be
> analysed.

I agree, and in fact Brett's work on a proper security model is greatly
welcome. It's just that us mere mortals need to use eval() *now*, and that
recipe is good enough for many practice uses. If you can't win, you can at
least lose with dignity :)
-- 
Giovanni Bajo

___
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

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

[Nick Maclaren]

"Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> 
> This recipe for safe_eval:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496746
> which is otherwise very cute, does not handle this case as well: it tries to
> catch and interrupt long-running operations through a secondary thread, but
> fails on a single long operation because the GIL is not released and the
> alarm thread does not get its chance to run.

Grin :-)

You have put your finger on the Great Myth of such virtualisations,
which applies to the system-level ones and even to the hardware-level
ones.  In practice, there is always some request that a sandbox can
make to the hypervisor that can lock out or otherwise affect other
sandboxes.

The key is, of course, to admit that and to specify what is and is
not properly virtualised, so that the consequences can at least be
analysed.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761Fax:  +44 1223 334679
___
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

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

[Giovanni Bajo]

Brett Cannon wrote:

>> The new doc is named securing_python.txt and
>> can be
>> found through the svn web interface at
>>
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log.

How do you plan to handle CPU-hogs? Stuff like execution of a gigantic
integer multiplication.

This recipe for safe_eval:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496746
which is otherwise very cute, does not handle this case as well: it tries to
catch and interrupt long-running operations through a secondary thread, but
fails on a single long operation because the GIL is not released and the
alarm thread does not get its chance to run.
-- 
Giovanni Bajo

___
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

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

[Lawrence Oluyede]

That's great. I just read your draft but I have little comments to do
but before let me say that I liked the idea to borrow concepts from E.
I've crossed the E's path in the beginning of this year and I found it
a pot of really nice ideas (for promises and capabilities). Here are
my comments about the draft:

- it's not really clear to me what the "powerbox" is. I think I got
the concept of "super process" but maybe it's to be clarified, isn't
it? It become clear in the "threat model" paragraph

- I hope no Rubystas will read the "Problem of No Private Namespace"
section because they have private/protected keywords to enforce this
stuff :-) Writing proxies in C will slow down the dev process (altough
will speed up the performance maybe) but in a far future someone will
come up with an alternative closer to the Python level

- Can you write down a simple example of what you mean with "changing
something of the built-in objects"? (in "Problem of mutable shared
state")

- What about the performance issues of the capabilities model overall?

- I know what you meant to say but the paragraph about pythonicness
and the security model seems a little "fuzzy" to me. Which are the
boundaries of the allowed changes for the security stuff?

- You don't say anything about networking and networked resources in
the list of the standard sandboxed interpreter

- Suppose we have a .py module. Based on your security model we can
import it, right? When imported it generates a .pyc file. The second
time we import it what happens? .pyc is ignored? import is not allowed
at all? We can't rely on the name of the file.pyc because an attacker
who knows the file.py is secure and the second import is done against
file.pyc can replace the "secure" file.pyc with an implementation not
secure and can do some kind of harm to the sandbox

- About "Filesystem information". Does the sandboxed interpreter need
to know all that information about file paths, files and so on? Can't
we reset those attributes to something arbitrary?

- About sys module: I think the best way is to have a purged fake sys
module with only the stuff you need. pypy has the concept of faked
modules too (altough for a different reason)

- About networking: what do you think about the E's model of really
safe networking, protected remotable objects and safe RPC? Is that
model applicable to Python's in some way? We can't use the E's model
as a whole (ask people to generate a safe key and send it by email is
unfeasible)

- is the protected memory model a some kind of memory monitor system?

I think that's all for the draft. I wrote these comments during the
reading of the document.

Hope some of these help

-- 
Lawrence
http://www.oluyede.org/blog
___
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

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

[Michael Foord]

Michael Foord wrote:
> Brett Cannon wrote:
>   
>> After various people suggesting object-capabilities, takling with Mark 
>> S. Miller of the E programming language, and the people Mark works 
>> with at HP Labs (who have been giving talks every week during this 
>> month here at Google on object-capabilities), I have decided to go 
>> with object-capabilities for securing interpreters.  I have rewritten 
>> my design doc from scratch and deleted the old one.  The new doc is 
>> named securing_python.txt and can be found through the svn web 
>> interface at 
>> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
>>  
>> 
>>  
>> .  I have pretty much ignored any concrete API and such and gone more 
>> with a conceptual doc to make sure the API does not get in the way of 
>> the core security model.
>>
>> 
>
> This may not be relevant or  possible, in which case I apologise, but 
> the .NET model of creating application domains is extremely useful. It 
> allows you to assign domains and run code within those domains. This 
> means, for example, you can create a plugin system and run the plugins 
> in a secure domain.
>
> I realise that this was the intent of the original rexec module, and 
> your proposed new design (which is very exciting) overcomes the 
> difficulties in that approach. The only approach using the new system 
> would be interprocess communication (?) with a trusted interpreter 
> communicating with an un-trusted one. Would the communication layer need 
> to be implemented as a C extension, or will a standard Python API be 
> possible ? Hmmm maybe I should read your doc. :-)
>
>   
Ok, started to read the doc - and realise it specifically addresses 
these issues. My apologies :-)

Michael
http://www.voidspace.org.uk/python/index.shtml

> Michael Foord
> http://www.voidspace.org.uk/python/index.shtml
>
>   
>> Using object-capabilities should make the implementation much 
>> cleaner.  There is much less work directly on the interpreter and more 
>> of it gets pushed up to extension modules.  I also have the okay of my 
>> supervisor to use this approach in my dissertation so this will get done.
>>
>> Two things do fall out of all of this which will make development much 
>> more modular and easier.  First, the memory cap work just becomes a 
>> special build on its own; no need to tie into the security work.  So I 
>> will be cleaning up the bcannon-sandboxing branch code as it stands, 
>> and then either create a separate branch for the object-capabilities 
>> work, or create another branch for the memory cap stuff and shift the 
>> changes over there.  I will most likely do the former so as to not 
>> lose the history on the checkins.
>>
>> I also plan to rewrite the import machinery in pure Python.  This will 
>> make the code much more maintainable and make creating proxies for the 
>> import machinery much easier.  I will be doing that in a directory in 
>> the sandbox initially since it needs to work from what Python has now 
>> (and possibly some new extension module code) before it can be 
>> integrated into the interpreter directly.  Anyone who wants to help 
>> with that can.  I already have some perliminary notes on the whole 
>> thing and I think it will be reasonably doable.
>>
>> Anyway, there you go.  Here is to hoping I have thought this all 
>> through properly.  =)
>>
>> -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/fuzzyman%40voidspace.org.uk
>>   
>> 
>
> ___
> 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/fuzzyman%40voidspace.org.uk
>
>   

___
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

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

[Michael Foord]

Brett Cannon wrote:
> After various people suggesting object-capabilities, takling with Mark 
> S. Miller of the E programming language, and the people Mark works 
> with at HP Labs (who have been giving talks every week during this 
> month here at Google on object-capabilities), I have decided to go 
> with object-capabilities for securing interpreters.  I have rewritten 
> my design doc from scratch and deleted the old one.  The new doc is 
> named securing_python.txt and can be found through the svn web 
> interface at 
> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
>  
> 
>  
> .  I have pretty much ignored any concrete API and such and gone more 
> with a conceptual doc to make sure the API does not get in the way of 
> the core security model.
>

This may not be relevant or  possible, in which case I apologise, but 
the .NET model of creating application domains is extremely useful. It 
allows you to assign domains and run code within those domains. This 
means, for example, you can create a plugin system and run the plugins 
in a secure domain.

I realise that this was the intent of the original rexec module, and 
your proposed new design (which is very exciting) overcomes the 
difficulties in that approach. The only approach using the new system 
would be interprocess communication (?) with a trusted interpreter 
communicating with an un-trusted one. Would the communication layer need 
to be implemented as a C extension, or will a standard Python API be 
possible ? Hmmm maybe I should read your doc. :-)

Michael Foord
http://www.voidspace.org.uk/python/index.shtml

> Using object-capabilities should make the implementation much 
> cleaner.  There is much less work directly on the interpreter and more 
> of it gets pushed up to extension modules.  I also have the okay of my 
> supervisor to use this approach in my dissertation so this will get done.
>
> Two things do fall out of all of this which will make development much 
> more modular and easier.  First, the memory cap work just becomes a 
> special build on its own; no need to tie into the security work.  So I 
> will be cleaning up the bcannon-sandboxing branch code as it stands, 
> and then either create a separate branch for the object-capabilities 
> work, or create another branch for the memory cap stuff and shift the 
> changes over there.  I will most likely do the former so as to not 
> lose the history on the checkins.
>
> I also plan to rewrite the import machinery in pure Python.  This will 
> make the code much more maintainable and make creating proxies for the 
> import machinery much easier.  I will be doing that in a directory in 
> the sandbox initially since it needs to work from what Python has now 
> (and possibly some new extension module code) before it can be 
> integrated into the interpreter directly.  Anyone who wants to help 
> with that can.  I already have some perliminary notes on the whole 
> thing and I think it will be reasonably doable.
>
> Anyway, there you go.  Here is to hoping I have thought this all 
> through properly.  =)
>
> -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/fuzzyman%40voidspace.org.uk
>   

___
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

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

[Ka-Ping Yee]

On Wed, 19 Jul 2006, Brett Cannon wrote:
> I have decided to go with object-capabilities for
> securing interpreters.  I have rewritten my design doc from scratch and
> deleted the old one.  The new doc is named securing_python.txt and can be
> found through the svn web interface at
> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log.

This is amazing news!!  I'm going off to read your document right now.


-- ?!ng
___
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