On Tue, Mar 6, 2012 at 2:34 AM, Adam Jon Richardson <adamj...@gmail.com>wrote:
> 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. > Hi, I've been thinking through the idea of sandboxed versions of the include and require language constructs, and here are some more ideas. Some expressed concerns about how difficult sandboxing is to get right. Reflecting on this, I agree that the difficulty is extreme. However, it's precisely because of this difficulty that this type of language feature would hold much value. Some expressed concerns about how difficult sandboxing could make it to develop plugins in applications like Drupal, Wordpress, etc. I don't see this as an issue, as many plugins need only very primitive features (e.g., a Wordpress plugin that is adding Google Analytics functionality to a blog), those plugins that require more access can be granted more access through the function's whitelist, and there would still be the standard (non-sandboxed) versions of require and include that can be used. Sandboxing should prevent reading/writing from/to any part of the environment not purposely exposed by the application/framework. That is to say that the application/framework should have the ability to govern the access to php settings, files, databases, etc. This would require limiting PHP code within included files by: - Raising an error for calls to functions not whitelisted (either by default or manually in the function call.) - Raising an error for attempts to instantiate object interfaces not whitelisted (some extensions like mysqli have function- and object-based interfaces.) Of note, the application/framework would be able to pass in an object interface for use within the included file. An example of the code using a sandboxed include could be as follows for a plugin that uses the mysql PDO extension: sandboxed_include('file/path', array('SANDBOX_PDO','SANDBOX_MYSQL_PDO')); I've started a simple list of safe (whitelisted) vs unsafe extensions/function/objects: http://adamjonrichardson.com/php-sandbox-safety.php Of note, it's a very quick, limited start. I'll spend some time over the next few weeks going through extension-by-extension, function-by-function looking to improve the list. I just wanted to put the idea out there for more feedback while I'm working on more ideas. Additionally, while the sandboxes would largely be broken up by extension (as categorized in the PHP website), some exceptions did seem reasonable (e.g., while most date functions are OK, few included files should need the ability adjust the default timezone for the app.) Thanks for the feedback, Adam
