Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58683
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
Received-SPF: pass (google.com: domain of keisial@gmail.com designates 10.216.133.39 as permitted sender) client-ip=10.216.133.39;
Message-ID: <4F567FD9.2050609@gmail.com>
Date: Tue, 06 Mar 2012 22:21:29 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Adam Jon Richardson <adamjonr@gmail.com>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
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>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Providing sandboxed versions of include and require
 language constructs
From: keisial@gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)

On 06/03/12 14:04, Adam Jon Richardson wrote:
> 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
It's not that easy. The internal functions could be splitted to
safe/unsafe (according
tosome definition, which would itself be a controversial one) but all
functions defined
outside would be injection candidates, too. Suppose you modified the
function
hash table to store if it's a limited function or it should be run with
high privileges.
Now, you need to audit the whole framework so that no can be tricked
into doing more
things than it should, if called from low-privilege code.
Which is pretty hard when that code could be corrupting your variables.
For instance, a safe framework function to perform database queries,
could become
unsafe by changing the db configuration (usually stored on globals),
allowing connections
to arbitrary servers.
Or a malicious plugin could register a class with the same name as a
framework one, before
the autoloader loads the right one, and have it used by privileged code.

PHP is not designed to use it that way, so unless there is an high level
way to do it, it's probably
impossible to do right. Maybe you can perform a full global replacement
when calling
untrusted code. That might work.