[Python-Dev] Re: rexec.py unuseable

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


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