( Jump to the original submission )
Sat 30 Jun 2012 11:04:03 AM UTC, comment #7: Closing as work got done and nothing new has happened for a while.
However, I invite those interested in the Lua security model to comment on bug #19729 ; we need some sort of answer for 2.4.0.
Sat 12 May 2012 09:33:55 PM UTC, comment #6: Any reason to keep this ticket open? There's been no movement on it for quite some time.
Sun 18 Apr 2010 08:34:06 PM UTC, comment #5: The way this is developing, no further changes are planned for the 2.1 branch. 2.1 branch has only had the directly unsafe/unwanted functions removed (read/write/execute programs etc).
Wed 14 Apr 2010 03:09:02 PM UTC, SVN revision 17342: API: Hide Lua module 'debug'
We load the debug library, but do not make it available in the
Lua API. The debug module allows access to (among other things) the
registry, and upvalues (local variables of closures).
See gna bug #15725
(Browse SVN revision 17342 )
Wed 14 Apr 2010 03:08:51 PM UTC, SVN revision 17341: API: Hide Lua module 'debug'
We load the debug library, but do not make it available in the
Lua API. The debug module allows access to (among other things) the
registry, and upvalues (local variables of closures).
See gna bug #15725
(Browse SVN revision 17341 )
Wed 14 Apr 2010 01:16:10 PM UTC, comment #2: To clarify the last comment:
We hide '.get', but the tolua runtime will use it to look up object fields. This will be type safe, unlike direct access to the ".get" table.
We remove '.set', so the tolua runtime will not allow writing back object fields (see bug #15696 ).
Wed 14 Apr 2010 01:10:51 PM UTC, comment #1: Here is a plan:
No unsafe functions (should be done)
No NULL pointers and no wild pointers (in progress):
1. We check arguments everywhere. Script functions should try to assure success or raise a script error.
2. Debug module hidden to disallow access to stuff that we hide (below)
No NULL pointers and no wild pointers (planned):
3. Limit access to the 'tolua' module (tolua.cast etc)
4. Remove access to all the API types' metatables (The table ".get" contains unprotected C function calls to look up object fields (.id, .name, .owner etc). Remove access to ".set" (all fields should be read-only, objects will be mutable by adding methods/setters instead)
Are these goals too ambitious? In particular, item 1 is much more ambitious than it sounds like. (Depending on the API function of course).
Sun 28 Mar 2010 10:55:57 AM UTC, original submission: I think it is best to be conservative: Security is hard, and we have no reason to believe the script runtime is secure against exploits.
(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)
Attach File(s):
Comment:
No files currently attached
Follow 9 latest changes.