On 06.08.2024 at 20:59, Niels Dossche wrote: > 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".
I concur. The old <https://pecl.php.net/package/runkit> did provide a "sandbox" feature, but that had not been ported to <https://pecl.php.net/package/runkit7>, possibly for exactly these reasons. > 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. Christoph
