[Discussion] Sandbox API

Hey Nick,

Looking forward to the RFC!

This looks quite valuable, and I assume auto loading would work just
like normal? Register an autoloader that will eventually require the
file and call this function?

It would be nice to provide a simplified api as well, maybe
“CopyCurrentEnvironment()” or something? In most cases, it is
easier/faster to find things to remove vs. adding everything on every
plugin/request every time.

In saying that, it would be great if there was an api for “sharing” a
base-sandbox pool via shm (or similar to a pool) so that the base vm
doesn’t need to be recreated potentially hundreds of times per
request.

I didn't want to be too overwhelming on the first post, but since it
seems the feedback is positive, here's a more complete list of what I
think should be included:

// Passthroughs:

// Make all user and built-in global functions
// available inside the sandbox:
SPLSandBox::PassGlobalFunctions();

Bike shed: maybe have PassGlobals() instead? Or rather, PassNamespace and have \ be a valid namespace.

// Make all built-in (but not user) functions
// available inside the sandbox:
SPLSandBox::PassBuiltInFunctions();

// Make all built-in (but not user) functions
// available inside the sandbox, EXCEPT blacklisted functions:
SPLSandBox::PassBuiltInFunctionsExcept(['eval','exit']);

(assuming exit becomes a function).

I feel like exit (function or not) should just return from the sandbox and shouldn’t be disable-able. For example, a plugin might detect a valid etag and set headers to 302 and exit.

// Allow only specific functions to be called (whitelist method):
$aWhiteList = ['array_key_exists','in_array'];
SPLSandBox::PassFunctions($aWhiteList);

Might be a good idea to combine these two? Allow passing a whitelist AND a blacklist? Are these supposed to be static or on an instance of a sandbox?

// Allow specific classes to be used by sandbox code:
$aClassList = ['\MyAPP\PluginAPI'];
SPLSandBox::PassClasses($aClassList);

// Allow specific constants to be seen by sandbox code:
SPLSandBox::PassConstants(['\DB_USERNAME','\DB_PASSWORD']);

// Language Construct Callbacks:

The callbacks allow the outer code to control and monitor certain
language features of the sandboxed code during execution.

// Called when the sandbox code tries to include or require something:
SPLSandBox::RegisterIncludeHandler();

Does including a file from outside the sandbox (next call) call this handler?

// Includes a file into the sandbox:
SPLSandBox::Include('path/to/file.php');

// Your sandbox autoloader logic could be incorporated here:
SPLSandBox::RegisterAutoLoadHandler();

// But, for unit testing with mocks and stubs,
// it might be better to use:
SPLSandBox::RegisterNewHandler();

The NewHandler callback is called every time sandboxed code tries to
instantiate an object with new.

Why not use the current autoload logic?

// Example: Override what new returns to code running in the sandbox:
function MyNewHandler(string $ClassName, array $aConstructorArgs){

if($ClassName === '\DateTime'){
return new FakeDate();
}
return new $ClassName($aConstructorArgs);
}

// Every time a sandboxed class calls a method, call this first:
SPLSandBox::RegisterMethodCallHandler();

Useful for unit testing to monitor if the tested class is calling the
methods it should be calling. Ignores visibility rules.

Could also allow for infinite recursion detection from the outside.

I think this is handled automatically now.

// The companion for static method calls, gets called
// every time a method is called on a class statically:
SPLSandBox::RegisterStaticMethodCallHandler();

// Each time a sandboxed loop iterates, call this first:
// Allows the outer code to put limit breaks on the sandboxed code.
SPLSandBox::RegisterLoopHandler();

The callback takes the type of loop, and the variables that make up the
loop ($i for for(), $Key => $value for foreach(), etc)

// If the sandboxed code calls echo, print, or
// causes any output to occur (ie outside of <?php tags:
SPLSandBox::RegisterEchoHandler();

Could be used to make sure templates behave as desired, but perhaps
even more useful, it lets you fail unit tests if any output occurs
from a test that shouldn't produce output.

ie. Catch echo statements used in testing, or whitespace after a
closing ?> tag.

// If the sandbox code tries to use exit or die,
// call this function instead:
SPLSandBox::RegisterExitHandler();

You'll probably want to destroy the sandbox from the outside (see
below), rather than letting sandboxed code halt the test framework or
main application.

// If sandboxed code throws, it should not
// be a throw in the outer application space.
// Every exception throw triggers this callback,
// even if there is a catch block:
SPLSandBox::RegisterExceptionHandler();

// When a catch block runs, invoke this callback first:
SPLSandBox::RegisterCatchHandler();

Allows unit tests to make sure that exceptions are handled correctly.

// For non-Exceptions (warning, notice, deprecated, fatal,
// and yes, maybe even parse because we're in a sandbox):
SPLSandBox::RegisterErrorHandler();

// Inside your Handlers, you may want to know the file and line
// that triggered the callback.
SPLSandBox::GetCurrentLine();
SPLSandBox::GetFileName();
SPLSandBox::GetClassName();
SPLSandBox::GetFunctionName();

For example, if you want to catch any echo left behind from debugging,
you might also want to find the line and file where the statement is
located to remove it. The above methods would be usable inside any of
the callbacks.

// Inside your Handlers, abort execution:
SPLSandBox::Stop();

// Resource Limits, hopefully self explanatory:
SPLSandBox::SetMemoryLimit();
SPLSandBox::SetExecutionTimeLimit();

// Mocks, Stubs:

// Put a function from the outer application
// into the sandbox as the specified name:
SPLSandBox::MockFunction('\mocks\fopen','\fopen');

// Put a class from the outer application
// into the sandbox as the specified name:
SPLSandBox::MockClass('\Mocks\FakeTime','\DateTime');

// Set global variables (and super globals) inside the sandbox:
SPLSandBox::MockGlobal('$_GET',$aGetVars);

// Set global constants inside the sandbox:
SPLSandBox::MockConstant('MY_CONSTANT',$Value);

// Invocation

// You can run procedural code to setup your test environment.
// Runs the array of code lines in the sandbox context:
$aProceduralCode = [
"$a = 1;",
"$b = 2;",
"$c = DoSomething($a, $b);"
];

SPLSandBox::Procedure($aProceduralCode);

// You can get a pointer to an object instantiated in the sandbox:
$oClass = SPLSandBox::GetInstance('ClassName');

// And use it like you normally would:
$oClass->DoSomething();

This class runs entirely in the sandbox.

// You cleanup the resource with:
SPLSandBox::Destroy();

Looks pretty exciting and useful! Since you’re imagining it being a part of SPL, why not implement this in its own extension? It looks like the pecl process is pretty convoluted to get an extension listed there, but many popular extensions live outside of pecl too.

— Rob

Hey Niels,

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?

— Rob

Hi Rob

I'm not a sysadmin guy or anything like that, so I don't know how shared hosting stacks looks like in practice.
But containers, chroot jails, seccomp-bpf, ... can offer protection. And you should be doing those things anyway (as a matter of defense-in-depth) if you're offering servers running untrusted code.

Kind regards
Niels

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?

php is not inherently insecure. not even remotely and quite the opposite.

Shared hosting is.

This is issue is not specific to php, almost all languages out there will
have the same memory (or else) challenges.

Crypto apis or similar features requiring high level of safety for the data
use various technics to mitigate it (zeroing after use, decrypt mem on
demand only etc).

A bit off topic but with the solutions out there for vps, etc, shared
hosting for anything requiring data safety should be avoided like the pest.

About this feature, it looks, at a first glance, like an advanced complex
version of safe mode/open base dir, with the additional features. I never
ever had to mock core functions for testing, I would think about a design
issue if it is needed.

But I may be wrong, that would not be a first :)

cheers,
Pierre

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

Hey Niels,

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?

— 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.