Re-authorize submodule imports if top was allowed #1103
Conversation
There was a problem hiding this comment.
Thanks for your contribution and addressing this problematic issue.
Just for the record:
- Many packages include dangerous submodules
- Before we restricted some dangerous submodules, but the blacklist was never (and will never be) fully comprehensive
- To improve security, we implemented a different approach: use a deny-by-default policy and allow the user to whitelist specific submodules that they consider safe for their use case, rather than trying to maintain an incomplete blacklist
Now you propose to revert to the previous approach:
- I think we should inform the security team: previously reported and fixed vulnerabilities will be exploitable again
|
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
|
Just to add my 2 cents: if the choice is to either 1. Extrapolate user imports or 2. Don't extrapolate but allow to specify each import, I am humbly suggesting 3. Don't extrapolate but allow regex to specify include and exclude imports. Something like: |
@albertvillanova this PR re-adds authorization for submodules whose top module was allowed, like authorizing access to
numpy.randomifnumpywas authorized. We need to be careful to avoid this potentially allowing harmful submodules of authorized modules, buttests/test_local_python_executor.py::TestLocalPythonExecutorSecurity::test_vulnerability_via_submodulesshould catch this vulnearbility?