[Python-Dev] doc for new restricted execution design for Python

[Brett Cannon]

On 7/5/06, Ka-Ping Yee <python-dev at zesty.ca> wrote:
>
> On Wed, 5 Jul 2006, Brett Cannon wrote:
> > On 7/4/06, Ka-Ping Yee <python-dev at zesty.ca> wrote:
> > > In response to Guido's comment about confusing the words "trusted" and
> > > "untrusted", how about "empowered" and "restricted"?
> >
> > Maybe.  I am really starting to lean towards trusted and sandboxed.
>
> It can be risky to use words of the form '*trust*' when talking
> about security because 'trust' can have different meanings in
> different contexts.  (Examples: 'X is trusted' might mean 'X is
> something i feel safe running without restrictions' or 'X *is*
> in fact allowed to run without restrictions' or 'i need to run X
> without restrictions in order to accomplish my task' or 'X is
> something i am relying on for the security of my system'.)
>
> The most common context for 'trusted' that i seem to come across
> is in the phrase 'trusted computing base' (TCB), which refers to
> 'the thing that is supposed to be enforcing security restrictions'
> as opposed to 'something i'm willing to let run unrestricted'.
> So when i read 'trusted code' what comes to mind is the C implementation
> of the Python interpreter, and it may be a good idea to reserve that
> phrase for that purpose, if it's to be used at all.
>
> In any case, let's try to nail down clear names for the different
> pieces we're talking about here, and i gently advise avoiding
> '*trust*' words or using them with very limited meaning.


For the next draft I am going with "trusted" and "sandboxed" just because I
have already revised a decent amount and it is what my brain is defaulting
to right now, but I can change the wording later.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060706/fa853fe3/attachment.html