Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58661
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.241 as permitted sender)
To: Adam Jon Richardson <adamjonr@gmail.com>, Stas Malyshev
	<smalyshev@sugarcrm.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Date: Tue, 6 Mar 2012 09:03:27 -0500
Thread-Topic: [PHP-DEV] Providing sandboxed versions of include and require
 language constructs
Thread-Index: Acz7mbSVmaVYWo7bQWO9y5kUYLHb7gABSk8Q
Message-ID: <A633CF2D7C7BED41B41F1E64F25507B8069DC470E5@MAILR001.mail.lan>
References: <CAJzDObekVt_F6JZP-B-YCs0khvfcSDW1PNeC6Bf5LUk=xPqVAQ@mail.gmail.com>
	<4F55DB1F.5040108@sugarcrm.com>
 <CAJzDObcwd6KMSNvJa8mui0QGiof+BEMoJ2WuGEq09uN+yc4n+g@mail.gmail.com>
In-Reply-To: <CAJzDObcwd6KMSNvJa8mui0QGiof+BEMoJ2WuGEq09uN+yc4n+g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] Providing sandboxed versions of include and require
 language constructs
From: johncrenshaw@priacta.com (John Crenshaw)

>> Hi!
>>
>>  Thoughts?
>>>
>>
>> This is a fine idea, however actually doing it is not that easy. Note=20
>> 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,=20
>> while passing all kinds of arguments - is it safe or not? It depends=20
>> on the context - e.g. plugin may need access to the database -=20
>> directly or through some API - but that opens the door to various SQL=20
>> injections and other mischief, etc. etc.
>> So while the idea is fine, designing a working sandbox is a very=20
>> complicated task. That said, if you have any ideas - you're welcome to=20
>> propose.
>
>
> The sandbox I'm considering would only impact the ability to directly cal=
l
> 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 function=
s
> (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 ide=
a.
> 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 entir=
e
> classes of functionality. For example:
>
> include_restricted('file/path', $whitelist =3D array('SANDBOX_FILE',
> 'SANDBOX_PDO', 'SANDBOX_MYSQL', 'SANDBOX_SOCKET'));
>
> If an error was raised because an included file required additional acces=
s,
> the error message could detail the exact constant(s) that would have to b=
e
> whitelisted for the include to be allowed.
>
> Thank you for the feedback, Stas. The questions and concerns raised in th=
is
> discussion help considerably.
>
> Adam

I've seen a simple "safe" code evaluator put together using token_get_all. =
I'm certain that you could create an include_restricted() function in userl=
and using a similar system: walk through the tokens looking for anything fo=
rbidden (this will be tricky, because there are a lot of nooks that things =
could hide, like superglobals), then if everything looks good include the f=
ile. Use a caching system of some sort to improve performance and eliminate=
 redundant checks.

I seriously doubt that this would ever get implemented in the core though. =
PHP has been moving away from this sort of thing (and for good reason). Att=
empting a "one size fits all" sandbox in the core just doesn't make any sen=
se.

John Crenshaw
Priacta, Inc.