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
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>.