Hi @natevw. You bring up a good option for Python sandboxing using PyPy. We looked at PyPy in general early in the HLA development but found it had some limitations that made it unsuitable for our use case. In particular it has a lot of difficulties and caveats with interacting with C/C++ code. This is critical for us both for being able to interoperate with our C++ backend, and for supporting important Python extensions like NumPy. This also limits the usefulness of the sandbox, since we need to allow shared-memory interactions with C++ that (as the PyPy documentation highlights) create a lot of opportunities for escape.
Also with respect to PyPy’s sandboxing, it is not to my knowledge used in any popular program that has to deal with significant adversaries analyzing it or has gone through an audit. Even browser JS engines which are the most examined JIT sandboxes available have code generation vulnerabilities with some regularity, so I have some doubts that this would be an effective way to sandbox the application.
We are also limited in what process-level sandboxing we can do on the backend, since it must interact with raw USB devices on each platform. This would necessitate splitting the backend into a multi-process model on all three of our major platforms, similar to Chrome’s sandbox model. This would be made much more difficult by the high data rate we need to be able to handle from the USB devices, which rules out some simpler IPC strategies. In short, it would require a sandboxing strategy of which the only examples I’m aware of are the major browser vendors, which have a far broader and more aggressive threat model than we do.