On Wed, 8 Jan 2003, "Martin v. L=F6wis" wrote: > Kevin Jacobs wrote: > > It has been said that the previous rexec functionality was ad hoc a= nd > > brittle, and many better solutions are possible. What better alter= natives > > exist in terms of features offered, overall runtime performance, ea= se of > > maintenance, and validation? >=20 > I disagree with that statement. The approach taken by rexec is very=20 > straight forward, and, in principle, allows to impose arbitrary=20 > functional restrictions on untrusted code. Good. I only partly agree with it myself. However, rexec _is_ brittle, = as demonstrated by the many incremental problems that keep popping up, even pre-Python 2.2. > So anybody working on this should see how rexec could be enhanced. IMO,= =20 > of course. I agree, though seeing how it can be fixed is not the same as deciding th= at it is the optimal solution. I'm starting out with a very open mind and a= m purposely solicting for as much input as possible. > > Proxy objects -- making unsafe objects safe(r) [...] > > Restricted introspection -- limiting the amount of information > > obtainable from exposed objects and > > environment >=20 > Can somebody please explain how this is different from restricted=20 > environments? I.e. why would one restrict introspection in general, as=20 > long as you can't obtain information about the system? The closure of all objects reachable (via introspection) from a given starting set can be _very_ large and non-trivial to compute.=20 Limiting introspection is a simple way to close many of possible holes through which references to untrusted objects can be obtained. > > Tainting -- tracking trusted status of objects >=20 > This is clearly out of scope of rexec, and, IMO, not relevant for=20 > untrusted code. Tainting is about processing untrusted data by trusted = code. I don't think it is so clearly out of the scope of the space of all possi= ble restricted execution enviornments. Tainting (used in a fairly liberal sense) is one way to propogate the security status of objects without hav= ing to proxy them. > > Security policy management -- Configuration of how security mechani= sms are > > applied >=20 > I think rexec is quite flexible here, giving or denying access on a=20 > per-function basis (and allowing to provide wrappers for functions whic= h=20 > must be restricted depending on the set of arguments). I agree. Thanks for your input, -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4