Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124822
Message-ID: <d39df742995d29e7db245891c517f0e2b68b041a.camel@ageofdream.com>
Subject: Re: [PHP-DEV] [Discussion] Sandbox API
To: internals@lists.php.net
Date: Wed, 07 Aug 2024 08:09:04 -0400
In-Reply-To: <ffc9c850-06f1-4937-be55-b9e2cc614dfb@app.fastmail.com>
References: <e08f6af322dcc5b4e4dd5e772f28be07ffa07ba4.camel@ageofdream.com>
	 <c510eb675bd0038efbbe5489bebd42ff7438e967.camel@ageofdream.com>
	 <7d9a9752-a202-4099-a60a-2686d4265d96@gmail.com>
	 <ffc9c850-06f1-4937-be55-b9e2cc614dfb@app.fastmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
Precedence: bulk
MIME-Version: 1.0
From: lists@ageofdream.com (Nick Lockheart)


> >=20
> > 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.
> >=20
> > Kind regards
> > Niels
> >=20
> Hey Niels,
>=20
> I find this assertion kind of scary from a shared hosting perspective
> or even from a 3v4l kind of perspective. How do these services
> protect themselves if php is inherently insecure?
>=20
> =E2=80=94 Rob


So I was thinking about this a bit more and I thought, what if instead
of adding a sandbox as a feature of PHP, what if PHP *was* the sandbox.

So consider this:

What if the PHP engine added a C API that lets C/C++ programs not only
spin up and run PHP, but those C/C++ programs could also control and
monitor the execution of the PHP environment from the outside.

That would essentially make every instance of PHP a sandbox.

But now, we would be able to control, monitor, and override certain
behavior from the outside while script execution runs.

This gives us a foundation to do two different things.


** Thing 1: A PHP extension for the PHP C API **

PHP's C API could then be controlled by a PHP script by using a PHP
extension that uses the PHP API. This would allow PHP scripts to spin
up and control instances of PHP, running in their own execution
context.

This meets the use case of Unit Testing scripts and secure execution of
third party plugins by PHP applications.


** Thing 2: C/C++ programs could use PHP as a library **

With a comprehensive C API to PHP, we could build C/C++ applications
that can use PHP scripts as a plugin.

Let's consider a use case for a social media site or ecommerce platform
that is high traffic and written in PHP.

What if we moved the front controller logic to a C application that was
built as an Nginx module?

Nginx Modules are statically linked, so now our front controller,
written in C, would be native inside Nginx, usable in location blocks.

Thanks to the C API for PHP, our front-controller-as-Nginx-plugin can
directly invoke parts of the PHP application as needed, and inject
resources directly into the PHP environment.

This isn't the same as a Fast CGI pass. This moves the routing, session
setup, and other redundant code into a native C application that's
actually part of the whole app.

So you could route requests, setup sessions, and serve cached pages as
fast as Nginx can process a request (about 1ms).

When the C land front controller needs to invoke PHP, it invokes PHP
through PHP's C API that lets the front controller pass data directly
into the PHP instance.

For example, the C front controller application can register a database
class inside the PHP environment that's already primed with an open
database connection (saves 20ms).

Because the running PHP application is actually talking back and forth
with the C land front controller, the C land front controller can
remember things (including session details) for faster responses.

This hybrid approach gives you the best of both worlds: Very fast
response times for most requests because the front controller and
sessions and other resources are handled in native C land, inside the
web server, while also giving you the flexibility, ease of use, and
rapid prototyping of PHP.