[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