security: call block_dangerous_modules during engine load#123
security: call block_dangerous_modules during engine load#123antojoseph wants to merge 2 commits into
Conversation
block_dangerous_modules was defined but never called in the production load path — only in tests. socket, subprocess, ctypes and multiprocessing were importable by provider-controlled vllm_mlx code despite the reported dangerous_modules_blocked capability being true. Call both lock_python_path and block_dangerous_modules at the top of load_vllm_mlx so both security layers are active in the same GIL scope that runs the model load.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7b4facbcf8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // here is safe (idempotent) and ensures the blocker is installed in the | ||
| // same interpreter state that will execute the model load. | ||
| Self::lock_python_path(py)?; | ||
| Self::block_dangerous_modules(py)?; |
There was a problem hiding this comment.
Delay dangerous-module blocking until model is loaded
Calling block_dangerous_modules() before _load_model() can break cold-start model loads when the model is not already cached: this function explicitly documents that load() may download weights if needed, and the new blocker removes/blocks socket and subprocess imports that Python download stacks rely on. In that scenario, load_vllm_mlx will fail before the engine initializes, so first-run providers cannot come up unless models are pre-downloaded.
Useful? React with 👍 / 👎.
_load_model may download weights from HuggingFace on cold starts, which requires socket and urllib. Blocking those modules before load caused first-run failures when the model was not pre-cached. sys.path is still locked before the load; the dangerous-module blocker is now installed after the engine is initialized and before inference requests are served.
Summary
block_dangerous_modules()was defined inprovider/src/inference.rsand covered by tests, but was never called in the productionload()pathsocket,subprocess,ctypes,multiprocessing, andfaulthandlerwere importable by provider-controlledvllm_mlxcode at inference time despitedangerous_modules_blocked: truebeing reported to the coordinatorlock_python_pathandblock_dangerous_modulesat the top ofload_vllm_mlx, in the same GIL scope that runs the model loadImpact
A malicious provider serving private text could import
socketorsubprocessto exfiltrate prompts or establish outbound connections from inside the hardened process.Test plan
test_block_dangerous_modules_blocks_importsstill passescargo test --features pythonpasses