[Python-Dev] rexec.py unuseable

[Luke Kenneth Casson Leighton]

On Mon, Dec 15, 2003 at 04:36:35PM -0500, Jeremy Hylton wrote:
> One kind of problem is that newer Python features were designed without
> taking rexec into account.  It's possible for untrusted code to cause
> the trusted interpreter to execute its code without restriction using
> descriptors.  It would be really difficult to reconcile new-style
> classes and rexec.  Perhaps a worthwhile project, but probably one
> accomplished by design a new restriction mechanism that builds on some
> of the basic mechanism of rexec.
 
 okay.

 i think the only really sensible way forward is to begin from a
 sound basis - one that is going to be a big job to add retrospectively,
 but a simple beginning can be made.

 proposal: how about building ACLs into the python codebase?

 the basic operations are read, write, execute and modify_acl

 the advanced operations are "applies-to-sub-objects" and
 "automatically-added-to-created-sub-objects".

 it should be easy to add more operations, both default ones AND
 user-defined ones.

 [the advanced operations are based on the new NT 5.0 (aka
  windows 2000) enhancements to the original VMS security
  model back from dave cutler's time when he worked for DEC
  and then he and his team got poached by microsoft to do
  NT, yes it's a long story.]
 
 the basic primitives are __get_acl__(), __set_acl__() and
 __check_acl__(operation_type).

 the acl should consist of a dictionary of aces [access control entries]
 where the name is the function or module name, and the value is an ace
 object.

 the objects should contain a __get_ace__() function and
 a __set_ace__() function.  the ace should contain a permission
 (read, write, execute, modify_acl etc.) and an "ALLOW" or "DENY"
 qualifier.


 the algorithm for evaluating an acl has been worked out already,
 and implemented originally by matthew chapman of the samba team,
 so code under the GPL already exists [in an NT-like environment which
 is over-the-top].
 
 the basics of the evaluation algorithm are that you pass in who
 you are (in this case, that's the function or module name), what
 type of operation you want to perform (read, write, execute, or
 combination of these) and the ACL.

 the aces are evaluated, looking through the dictionary (actually it's
 going to have to be a list of tuples now that i think of it because
 the order is important, due to the ALLOW and DENY attributes),
 checking first that the ACE name matches the "who am i" and then
 checking what type of permission was requested against the ACE
 entries.

 the tricky bit is the "inheritance" permissions, which create
 "shadow" ACLs or, more specifically, they "throw shadows" down
 the sub-objects, adding or removing permissions from all
 sub-objects.

 in this way, it is possible to implement rexec by simply removing
 the write permissions at the top level as an "inherited" permission.


 an empty acl means "anything goes" (including that of "any acl may be
 added to this object").

 an empty acl also means that there is no performance penalty for having
 acl code in the python codebase.

 l.