Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58641
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.36.99 as permitted sender) client-ip=10.182.36.99;
MIME-Version: 1.0
Date: Tue, 6 Mar 2012 02:34:13 -0500
Message-ID: <CAJzDObekVt_F6JZP-B-YCs0khvfcSDW1PNeC6Bf5LUk=xPqVAQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d04451787c6a93704ba8e118d
Subject: Providing sandboxed versions of include and require language constructs
From: adamjonr@gmail.com (Adam Jon Richardson)

--f46d04451787c6a93704ba8e118d
Content-Type: text/plain; charset=ISO-8859-1

Plugins are a big deal (see
http://oneofmanyworlds.blogspot.in/2012/03/difficult-decision.html for a
recent example.) In this era of mashups and breakneck innovation,
developers must rely on vast amounts of code they've never seen, let alone
audited. Wordpress, Drupal, and many other tools developed in PHP make
plugin development easy and extremely powerful. While these tools
constantly work to improve security (and, at least relatively, do a solid
job most of the time), there remains significant challenges due to globally
accessible functions that allow manipulation of the environment (files,
DB's, networking, etc.) Any plugin can use these global functions to work
around the security restrictions imposed by the framework, library, or CMS.

While code audits can locate the offending scripts, this is a challenging
task, both in terms of time AND abilities. Languages and/or environments
that can mitigate these issues for the developer, while far from fool
proof, do offer real value on the security front. Lua provides the ability
for developers to limit the functions available in the current environment:
http://lua-users.org/wiki/SandBoxes

PHP does have an extension that offers several forms of sandboxing: runkit.
However, it's often not available in shared host environments.

The include (and require) construct is the front door for any plugin code.
What if PHP offered functions that implemented sandboxed versions of the
include and require language constructs (e.g.,
included_restricted('file/path', $functions = array('file',
'file_get_contents')))? Functional specs could include:

1) Internal functions seen as universally safe would by default be allowed
(e.g, str_replace(), array_pop(), etc.)
2) Unsafe internal functions would have to be explicitly declared (e.g.,
file(), stream_*, etc.)
3) Any includes or requires within the sandboxed code would be forced to
meet the same restrictions. (tricky)
4) Code containing unsafe functions not included in the whitelist would
raise an error.

There would be a performance hit for code that actually used the sandboxed
functions to include scripts, but for many applications, I suspect this
would be worth the hit. Security is becoming more important by the day
(just ask github: http://homakov.blogspot.com/2012/03/how-to.html#), and
empowering the developer with tools to enforce greater restrictions on the
ever-growing heaps of unaudited code seems wise.

Thoughts?

Adam

--f46d04451787c6a93704ba8e118d--