[Python-Dev] Re: rexec.py unuseable (original) (raw)

Michael Chermside mcherm at mcherm.com
Wed Dec 17 08:56:37 EST 2003

Luke:

Seeing as you've now had time enough to read what I'd written, I was going to respond to some of the points that you made, but then I read Nick Coghlan's posting[1], and I really don't have anything else to add.

[1] http://mail.python.org/pipermail/python-dev/2003-December/041105.html

Well, that's not quite true... I guess I do have something small to add. In designing a security policy for file systems, there are very few things that you can do with the protected items. Separate "read", "write", and "execute" permissions seem appropriate. Furthermore, there tends to be a clear idea of a "user", and in many situations we want all access to items (files) to depend only on who that "user" is (sandboxing an email program is an exception... are you listening MS?). Finally, we often want to provide centralized administration of access rights to file systems. ACLs are a good match for these design specs.

However, controlling what arbitrary programs may do is a very different beast. First of all, the kinds of restrictions that we want are HIGHLY variable. Sometimes we want to prohibit all file access. Sometimes we want to allow read-only access to a certain file only. Sometimes we want access only to a certain directory. Sometimes we don't care at all about file system access, we're concerned instead with providing an object which can be queried but only in certain ways -- and the specifics of what is permitted and what isn't are completely dependent on the particular application.

On top of that, there's rarely a clear concept of "users" that controls what actions we want to permit. Instead, we usually want to allow or deny certain capabilities to particular sections of code. (Sometimes that will be a module, sometimes a plug-in, sometimes a child program.)

All of these things suggest that maintaining a list of who is permitted to access what is simply not the best model for providing security in a programming language. I think that capabilities ARE an excellent model. Sections of code already have the concept of "access" to certain objects and variables (at least since the invention of structured programming in the late 1960s). And if unforgability and private data structures are provided as elemental building tools, then it is relatively straightforward to write code that enforces whatever set of access rules is required, regardless of how complex it may be.

-- Michael Chermside

More information about the Python-Dev mailing list