On Tue, Mar 6, 2012 at 3:30 AM, Florian Anderiasch <flor...@anderiasch.de>wrote:
> Isn't that basically what all template engines tried to solve before > with giving you a defined subset of tokens that are more or less > directly converted to php code? The benefit I see is that plugin > developers wouldn't need to learn a new DSL (domain-specific language), > but use PHP code. Just that it's not PHP if you disable 90% of the > functions available. > I agree, many template engines do offer a controlled set of language constructs that limit the attack surface. However, DSL's tend to be focused on one specific problem area (such as templating, as you noted) as opposed to providing general programming capabilities, so building plugins in a DSL can be quite limiting in terms of potential power: http://martinfowler.com/bliki/DomainSpecificLanguage.html As another option, one could always develop a full-fledge programming language that compiles down to PHP (similar to CoffeeScript's compiling to JavaScript.) One can then use the language to abstract away calls to functions deemed unsafe without explicit permission. However, this requires learning a new programming language and would require the consumer of the script to perform compilation to ensure the security. I'm not sure how many functions would be disabled, but I estimate it's a much lower number than 90%. For instance, if a function is pure (i.e., has no side effects), that function would be considered safe. That said, I'll start sifting this list of functions and see what list I come up with: http://php.net/quickref.php > While the idea is certainly not bad, I'm not sure you could write > sensible plugins for applications with only a few string functions at > hand. My gut instinct tells me you'll run into something like "I wish I > had this dir() to get the files in this directory" more sooner than > later. Last plugin (for Drupal) I wrote for example hooked into the File > API and saves/retrieves uploads to/from MogileFS. So that's file access > AND network access, and those would quite probably the first on the list > to be blacklisted. And if you only blacklist a few, disable_functions > might be enough. > Valid points. Your Drupal plugin example could use several of the functions initially blacklisted. However, the developer would then be able to, upon reading the documentation and requirements for your plugin OR seeing the error raised when attempting to sandbox your script, make an informed decision as to how much they trust you, the provider of the script, and, whether the perceived risk is worth the value. If the value is enough, the developer would then be able to add the needed functions to the whitelist and run your plugin. Of note, the sandbox I'm suggesting would only impact internal functions within files included with the sandboxing function. If Drupal, for example, offered a file API and made it available to your plugin through the scoping rules inherent in the application, you would be able to call those functions without issue. The sandboxing would only limit direct calls to unsafe, internal functions. The idea is to limit the access to the environment that the framework or CMS can't properly limit. They can already limit access to their environment through the API, and this proposal would trust them to do that. The disable_functions directive is indeed very handy, but it forces you to give up the functions throughout the entire environment, whereas the sandboxing would be limited to the scope of specific includes. Additionally, shared host environments don't allow you to adjust this setting. To sum it up, to solve this problem I'd be more thinking about creating > a specific DSL (like puppet) to fill my needs and not try to make people > write some sort of 50%-PHP with constant lookup which functions are > allowed and which are not. > The hope would be that you wouldn't have to constantly look up the functions that are allowed. Rather, you'd use the functions you need and the consumer of your plugin would decide if your plugin merited trusting you with the "unsafe" internal functions you used. While the consumer might not be able to audit every plugin they use, the sandboxing would bring to light the plugins that needed extra attention and caution. Excellent feedback, Florain. Thanks! Adam
