0

I've been working on a Home Automation system now for a little more than a year and I've added a plugin system to it. I've also added so others can submit their plugins and if I accept them then they're automatically added to every system of mine connected to the internet. Now there's nothing wrong with the plugin system itself but i'm very concerned regarding the security.

I still want the plugin system to be able to run normal PHP code and do what the plugin was suppose to do but I don't want code like for example:

echo file_get_contents("../inc/db.php");

to work. I want the plugin sandboxed to an extent where it can still operate as a normal plugin and still be restricted enough to not touch or read any of the files that the system is running on.

The reason why I'm wondering is because I want the user to test out his plugin before he submits it obviously but I'm scared that if I let the user run PHP code by himself then he might compromise the system.

Is it possible to fix this somehow? If it helps the plugin is running in a different folder than the rest of the files.

Also

Is it possible to restrict so the plugin can't run certain functions such as shell_exec, exec, passthru, system without completely disabling it in php.ini?

2

Short answer is that you're not going to be able to achieve what your requirements.

A longer answer is that maybe you could write your own pre-processor to scan a submitted file for stuff you don't like - but this is really complex. An alternative approach would be to implement the plugin on a secondary php handler with a very extensive disable_functions ini setting running in a container (ideally a seperate server) and access the plugin as a webservice call. But I'm skipping over a HUGE amount of detail here which you really need to understand before this would be in anyway safe - and from the way you've asked the question, I think you've got a lot of learning to do before you would be in a position to take a good stab at it (there's a LOT more than the functions you listed which need to be disabled).

  • > write your own pre-processor to scan a submitted file for stuff you don't like - but this is really complex ... no, impossible. think "base64decode()", 'B' + 'a' + 'S' + 'e' ..., preg_replace and all other possible obfuscation-methods of mutating code and function_names. – that guy from over there Feb 14 '15 at 11:26
  • While I don't really want to encourage people to try this unless they know what they are doing....yes there are lots of ways to obfuscate and even encrypt code, but there are only a few ways to get php to execute code (popen, exec, et all, create_function, eval, include) – symcbean Feb 14 '15 at 15:08
1

To really "sandbox" your plugins from your application/system I think you need to implement an API that only allows access to certain application data and limit the php functions you don't want the plugins to use.

Since you're using php there's the php-fpm package that allows running multiple instances of php (even as different users). These instances can have separate ini settings that allow you to run plugins as a less-privileged user with heavily limited php_admin settings and connect internally to your application API.

This will of course add a lot of work initially, but It'd be worth it since security is important for you.

  • Adding to that I believe with the process running under a different user you can rely largely on the UNIX permissions model and just don't grant file permissions to that user from anywhere except perhaps temp and persistent storage, and the plugin directory. – zenware Jan 27 '17 at 23:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.