rexec.py unuseable

[Luke Kenneth Casson Leighton]

On Tue, Dec 16, 2003 at 05:37:34AM -0800, Michael Chermside wrote:
> Luke writes:
> >  i think the only really sensible way forward is to begin from a
> > sound basis...
> 
> I agree completely.
> 
> >  proposal: how about building ACLs into the python codebase?
> 
> Actually, I rather prefer the approach that has been mentioned before
> of trying to use capabilities. 

 capabilities, acls, schmapabilities, same thiiing :)

 a la "cambridge capability system" [a historic architecture that
 provided hardware-assisted restrictions on function calls!]


> See, for instance, the threads on
> Capabilities found here: 
> http://mail.python.org/pipermail/python-dev/2003-March/thread.html#33854
> Of course, that's not trivial to add either, since some way would
> need to be provided for disabling Python's powerful introspection.
 

> > 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].
> 
> Unfortunately, code under the GPL is of no use at all for Python which
> is released with a more flexible (but GPL compatible) liscense. And
> I'm not quite sure what you mean by an "NT-like environment" being
> "over-the-top".
 
 the algorithm is there, for people to examine.

 i wasn't recommending that people go for complete code reuse of what
 is in samba (even if licenses were compatible) because the code in
 samba is a _complete_ reimplementation of the NT acl system
 _including_ recreating the internals of ACLs and their on-the-wire
 representation.

 however, there is a less low-level library which uses ACLs as
 "blobs", and it is the implementation of the check security access
 function [name i forget] which is actually a _re_implementation
 of the exact NT equivalent function that i recommend people to
 examine.


> > an empty acl also means that there is no performance penalty for having
> > acl code in the python codebase.
> 
> Sorry, but I simply don't believe this. Really. Think about it a bit,
> and if you still think you're right, I'll provide some reasons, but
> I suspect you'll realize that it's simply not true.

 tiny, then.

 in function calling:

 if len(acl) == 0 or check_allowed_access(callee_function, acl,
		 EXECUTE_CAPABILITY):
 	proceed...

 and in file write, again:
 
 if len(acl) == 0 or check_allowed_access(callee_function, acl,
 	 	WRITE_CAPABILITY):
		proceed...

 yes, the len(acl) == 0 checks will stack up, but not terribly
 significantly IMO.

 if an acl _does_ exist, even if it's one that grants permission
 to all functions/modules the ability to perform _all_ operations,
 _then_ you get a performance hit as the check_allowed_access()
 function needs to "do work".


> I *DO* think though, that some amount of slow-down *IS* acceptable
> (pie or no pie <wink>) if it provided powerful new capabilities like
> *reliable* restricted execution environments.

 ack!

 btw yes you're right, it's better off called "capabilities"
 but the name CCLs - capability control lists - is a bit of
 a mouthful :)


 btw, as a first implementation, doing "recursive" capability
 permissions could be avoided, by simply "copying" permissions
 down the object tree.

 as can be imagined, this is rather wasteful of both time and
 resources, which is why someone at microsoft came up with
 the concept of "apply-to-sub-object" capabilities.

 but remember: if all your ACLs (sorry, CCLs) are 0-length, it's
 not a waste of either time _or_ resources.

 l.