Security Implications of Loading Resources¶
OxidizedFinder
allows Python code to define its own OxidizedResource
instances to be made available for loading. This means Python code can define
its own Python module source or bytecode that could later be executed. It also
allows registration of extension modules and shared libraries, which give
a vector for allowing execution of native machine code.
This feature has security implications, as it provides a vector for arbitrary code execution.
While it might be possible to restrict this feature to provide stronger
security protections, we have not done so yet. Our thinking here is that
it is extremely difficult to sandbox Python code. Security sandboxing at the
Python layer is effectively impossible: the only effective mechanism to
sandbox Python is to add protections at the process level. e.g. by restricting
what system calls can be performed. We feel that the capability to inject
new Python modules and even shared libraries via OxidizedFinder
doesn’t
provide any new or novel vector that doesn’t already exist in Python’s standard
library and can’t already be exploited by well-crafted Python code. Therefore,
this feature isn’t a net regression in security protection.
If you have a use case that requires limiting the features of
OxidizedFinder
so security isn’t sacrificed, please
file an issue <https://github.com/indygreg/PyOxidizer/issues>.