Re: [Discussion] Sandbox API

From: Date: Tue, 06 Aug 2024 18:59:03 +0000
Subject: Re: [Discussion] Sandbox API
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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


Thread (15 messages)

« previous php.internals (#124811) next »