Title: [RFC] Support embedding and sandboxing untrusted code · Issue #4210 · RustPython/RustPython · GitHub
Open Graph Title: [RFC] Support embedding and sandboxing untrusted code · Issue #4210 · RustPython/RustPython
X Title: [RFC] Support embedding and sandboxing untrusted code · Issue #4210 · RustPython/RustPython
Description: Summary As far as I have seen, RustPython is not yet suitable for "safe" embedding, meaning that executed Python code can block or hurt the caller code, because: execution can loop forever, memory allocation is not bounded, import cannot...
Open Graph Description: Summary As far as I have seen, RustPython is not yet suitable for "safe" embedding, meaning that executed Python code can block or hurt the caller code, because: execution can loop forever, memory ...
X Description: Summary As far as I have seen, RustPython is not yet suitable for "safe" embedding, meaning that executed Python code can block or hurt the caller code, because: execution can loop foreve...
Opengraph URL: https://github.com/RustPython/RustPython/issues/4210
X: @github
Domain: github.com
{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[RFC] Support embedding and sandboxing untrusted code","articleBody":"## Summary\r\n\r\nAs far as I have seen, RustPython is not yet suitable for \"safe\" embedding, meaning that executed Python code can block or hurt the caller code, because:\r\n\r\n- execution can loop forever,\r\n- memory allocation is not bounded,\r\n- import cannot be disabled.\r\n\r\n## Detailed Explanation\r\n\r\nI wish to use RustPython as a scripting language within a game engine, running third-party user code. A requirement for me is that this code is run in a safe way. As far as I have seen (but I might have missed some elements), it is currently not the case:\r\n\r\n- It is not possible to limit code execution up to a maximum number of instructions. Looking into RustPython's source, if I'm not mistaken, this feature would need to be added to `ExecutingFrame` in its [execution loop](https://github.com/RustPython/RustPython/blob/main/vm/src/frame.rs#L347). Maybe the [`ExecutionResult` type](https://github.com/RustPython/RustPython/blob/main/vm/src/frame.rs#L123) could be extended with an `InstructionBudgetExceeded` variant or similar (which could later be expanded to support step by step interactive debugging).\r\n- I couldn't find a way to set limits to heap allocation or stack size, that would also be needed.\r\n- My understanding is that [importlib is always enabled](https://github.com/RustPython/RustPython/blob/main/vm/src/import.rs#L34), but that the OS module is currently disabled in [Wasm32 or Wasi](https://github.com/RustPython/RustPython/blob/main/vm/src/import.rs#L42), is that correct? If so, there should be a way to have finer-control on import lib or even forbid user-defined import statements altogether. Also, I see no reason to link the control of the availability of the `os` module to WASM, maybe a feature flag would be a good addition. Similarly, it should be possible to not enable some [Windows specific code](https://github.com/RustPython/RustPython/blob/main/vm/src/import.rs#L45) and fully disable or controls IOs (including network) and side-effect functions (such as delay) regardless of the target platform.\r\n- Control of the garbage collection would be welcome (#4180), although not critical because one design could be that the RustPython context does not outlive a display frame.\r\n\r\n## Drawbacks, Rationale, and Alternatives\r\n\r\nThe rationale is to use RustPython as an embedding language within larger software, such as game engines. In these, the software must fully control the scripting environment's limits.\r\n\r\nThe main drawback is increased code complexity within RustPython, but I believe it can be done cleanly, with some work of course. The split of the Std library (#3102) was already a step towards the direction of embedding.\r\n\r\nThe alternatives are to not implement this feature, or do it in a fork. A similar issue exists (#3090), but it is more of a question, so I thought an RFC-style new issue is better.\r\n\r\n## Unresolved Questions\r\n\r\nThere are quite some design questions obviously, but I guess first one should agree whether this overall feature makes sense for the project, then the design can be worked out. Probably a unified way to control embedding would be elegant.\r\n","author":{"url":"https://github.com/stephanemagnenat","@type":"Person","name":"stephanemagnenat"},"datePublished":"2022-10-11T09:57:02.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":8},"url":"https://github.com/4210/RustPython/issues/4210"}
| route-pattern | /_view_fragments/issues/show/:user_id/:repository/:id/issue_layout(.:format) |
| route-controller | voltron_issues_fragments |
| route-action | issue_layout |
| fetch-nonce | v2:c1e729b1-b754-3d45-5bbe-a7bcda8f4697 |
| current-catalog-service-hash | 81bb79d38c15960b92d99bca9288a9108c7a47b18f2423d0f6438c5b7bcd2114 |
| request-id | AC26:134106:1296407:1865F6D:6A5BCFEE |
| html-safe-nonce | 0d3e1fbf2ff4cc2afff099dad47519429426e5d195cf03d638855e0751973476 |
| visitor-payload | eyJyZWZlcnJlciI6IiIsInJlcXVlc3RfaWQiOiJBQzI2OjEzNDEwNjoxMjk2NDA3OjE4NjVGNkQ6NkE1QkNGRUUiLCJ2aXNpdG9yX2lkIjoiNTYyMzU5NTM0NzUzNDkyNTgwNiIsInJlZ2lvbl9lZGdlIjoiaWFkIiwicmVnaW9uX3JlbmRlciI6ImlhZCJ9 |
| visitor-hmac | d34945947d2cced7284dc3f1b8e613f39f1d8c5af5874e34d28c95d0cee2c06d |
| hovercard-subject-tag | issue:1404357909 |
| github-keyboard-shortcuts | repository,issues,copilot |
| google-site-verification | Apib7-x98H0j5cPqHWwSMm6dNU4GmODRoqxLiDzdx9I |
| octolytics-url | https://collector.github.com/github/collect |
| analytics-location | / |
| fb:app_id | 1401488693436528 |
| apple-itunes-app | app-id=1477376905, app-argument=https://github.com/_view_fragments/issues/show/RustPython/RustPython/4210/issue_layout |
| twitter:image | https://opengraph.githubassets.com/53f655b7b1dde8606bed0cf04675da35bed6c6f8b86e6f6faafe541aba17c9c2/RustPython/RustPython/issues/4210 |
| twitter:card | summary_large_image |
| og:image | https://opengraph.githubassets.com/53f655b7b1dde8606bed0cf04675da35bed6c6f8b86e6f6faafe541aba17c9c2/RustPython/RustPython/issues/4210 |
| og:image:alt | Summary As far as I have seen, RustPython is not yet suitable for "safe" embedding, meaning that executed Python code can block or hurt the caller code, because: execution can loop forever, memory ... |
| og:image:width | 1200 |
| og:image:height | 600 |
| og:site_name | GitHub |
| og:type | object |
| og:author:username | stephanemagnenat |
| hostname | github.com |
| expected-hostname | github.com |
| None | 5290d7e14309ad1e76106a9c4237bd1041517e83ea182c8ab756752cb0c6940b |
| turbo-cache-control | no-preview |
| go-import | github.com/RustPython/RustPython git https://github.com/RustPython/RustPython.git |
| octolytics-dimension-user_id | 39710557 |
| octolytics-dimension-user_login | RustPython |
| octolytics-dimension-repository_id | 135201145 |
| octolytics-dimension-repository_nwo | RustPython/RustPython |
| octolytics-dimension-repository_public | true |
| octolytics-dimension-repository_is_fork | false |
| octolytics-dimension-repository_network_root_id | 135201145 |
| octolytics-dimension-repository_network_root_nwo | RustPython/RustPython |
| turbo-body-classes | logged-out env-production page-responsive |
| disable-turbo | false |
| browser-stats-url | https://api.github.com/_private/browser/stats |
| browser-errors-url | https://api.github.com/_private/browser/errors |
| release | 9c975978430e9ad293956f2bbdaf153b1bd84a99 |
| ui-target | full |
| theme-color | #1e2327 |
| color-scheme | light dark |
Links:
Viewport: width=device-width