On 06/08/2024 10:41, Nick Lockheart wrote: > > Sandbox: Security > > A SandBox has two use cases: > > 1. Unit Testing of code with mocks or stubs, and also, allowing testing > with different environments. > > 2. The secure running of 3rd party code inside a 1st party application. >
The use-case of securely running 3rd party code inside your application is impossible at this moment, and will still be impossible after a sandbox API is introduced. The reason is that the PHP interpreter as it is today is not memory safe. It is relatively easy to cause memory corruption by only using PHP code by abusing things like custom error handlers set from userland. This in turn can be used to gain arbitrary read/write primitives which has been shown to circumvent disable_functions & open_basedir, and some PoCs can even run arbitrary commands. It would be doable to extend these tricks to circumvent a sandboxing API. As such, a sandboxing API for securely executing 3rd party code is only possible after the interpreter has become memory safe. Although some work has been done in PHP 8.3 to plug many of these memory safety bugs in the VM, much more work remains and would likely require complicated changes. So therefore I propose to only focus on the mocking functionality of your proposal for now, until the time comes that the interpreter is memory safe. I would therefore also not call it "sandbox". Introducing a sandbox API for security also opens up a can of worms for the security policy. Right now we are assuming an attacker model of a remote attacker, and that the code running on your server is trusted. But that would change when an official sandbox API is introduced. Kind regards Niels
