Kevin Jacobs wrote: > It has been said that the previous rexec functionality was ad hoc and > brittle, and many better solutions are possible. What better alternatives > exist in terms of features offered, overall runtime performance, ease of > maintenance, and validation? I disagree with that statement. The approach taken by rexec is very straight forward, and, in principle, allows to impose arbitrary functional restrictions on untrusted code. Non-functional restrictions (code has to observe limitations in resource usage, such as computing time, memory consumption, or number of open files) are not easily implemented with rexec. I believe that any extension to provide such restrictions also would be orthogonal to rexec. So anybody working on this should see how rexec could be enhanced. IMO, of course. > Proxy objects -- making unsafe objects safe(r) I think the really tricky part today is usage of the type() builtin (i.e. access to an object's __class__ attribute). The new problem is that types are now callable. On one hand, you cannot hand out the true type objects to untrusted code, since they could use them to overcome the limitations. On the other hand, if the untrusted code merely uses the type objects for testing type membership, such code should continue to work. So you either need a way to disable calls to type objects, or you need proxy type objects around the builtin types. For proxy types, some types could be considered safe (e.g. int, str, unicode); others would need proxies (the file type in particular). > Restricted introspection -- limiting the amount of information > obtainable from exposed objects and > environment Can somebody please explain how this is different from restricted environments? I.e. why would one restrict introspection in general, as long as you can't obtain information about the system? > Tainting -- tracking trusted status of objects This is clearly out of scope of rexec, and, IMO, not relevant for untrusted code. Tainting is about processing untrusted data by trusted code. > Security policy management -- Configuration of how security mechanisms are > applied I think rexec is quite flexible here, giving or denying access on a per-function basis (and allowing to provide wrappers for functions which must be restricted depending on the set of arguments). Regards, Martin
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