Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
Received-SPF: pass (google.com: domain of adamjonr@gmail.com designates 10.182.38.7 as permitted sender) client-ip=10.182.38.7;
MIME-Version: 1.0
In-Reply-To: <4F55DB1F.5040108@sugarcrm.com>
References: <CAJzDObekVt_F6JZP-B-YCs0khvfcSDW1PNeC6Bf5LUk=xPqVAQ@mail.gmail.com>
	<4F55DB1F.5040108@sugarcrm.com>
Date: Tue, 6 Mar 2012 08:04:08 -0500
Message-ID: <CAJzDObcwd6KMSNvJa8mui0QGiof+BEMoJ2WuGEq09uN+yc4n+g@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0447f28ca8d67004ba92ad39
Subject: Re: [PHP-DEV] Providing sandboxed versions of include and require
 language constructs
From: adamjonr@gmail.com (Adam Jon Richardson)

--f46d0447f28ca8d67004ba92ad39
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 6, 2012 at 4:38 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
>  Thoughts?
>>
>
> This is a fine idea, however actually doing it is not that easy. Note that
> knowing which function is "safe" is pretty hard, but that's only a start.
> Plugin code, for example, can call functions outside plugin context, while
> passing all kinds of arguments - is it safe or not? It depends on the
> context - e.g. plugin may need access to the database - directly or through
> some API - but that opens the door to various SQL injections and other
> mischief, etc. etc.
> So while the idea is fine, designing a working sandbox is a very
> complicated task. That said, if you have any ideas - you're welcome to
> propose.


The sandbox I'm considering would only impact the ability to directly call
internal functions. The idea rests on the hope that the framework or CMS
provides a security model that protects the integrity of their own
environment. The framework can for example hand off whatever state
variables are deemed appropriate and necessary to a plugin. The framework
can make public whatever methods are appropriate and necessary. However,
the framework can't currently limit the direct calls to internal functions
(without parsing the PHP source and it's dependencies), which could allow
the plugin developer to circumvent the security policies of the framework.

Indeed, the complexity is extreme, even for the limited scope of this idea.
And, avoiding complexity for the developers using the sandboxed version
would be difficult, too.

I'm wondering if it would be easier to allow constants representing entire
classes of functionality. For example:

include_restricted('file/path', $whitelist = array('SANDBOX_FILE',
'SANDBOX_PDO', 'SANDBOX_MYSQL', 'SANDBOX_SOCKET'));

If an error was raised because an included file required additional access,
the error message could detail the exact constant(s) that would have to be
whitelisted for the include to be allowed.

Thank you for the feedback, Stas. The questions and concerns raised in this
discussion help considerably.

Adam

--f46d0447f28ca8d67004ba92ad39--