7

I’m developing a thing where I will have two very distinct components.

Structure at this moment is
Core:
Stuff inside the core
3prty:
Third party developed stuff

Now, what I want to do is to keep the third party developed php script from doing something like 

scandir("../");

or 

require "../core/anyfile.php";

or

file_get_contents("../core/SourceCode.php");

Is there anyway to make this happen? Any help is appreciated. Thanks in advance.

I am running Apache, and it’s my own server, so I can set up any extension etc. The solution must be viable for production envirement, and I need to be able to allow 3rd party script, knowing that they might be malicious.

SomeNorwegianGuy
  • 1,494
  • 4
  • 17
  • 43
  • 4
    possible duplicate of [Isolation in PHP?](http://stackoverflow.com/questions/5860439/isolation-in-php) – Lawrence Cherone Nov 14 '13 at 05:34
  • your best bet is likely going to be system level access control. for example, you can first include a php script to setup a chroot jail, but this can get tricky. what are your sysyem specs, and do you have privileges that will allow you to add additional php extensions or change other system configurations – JSON Nov 14 '13 at 05:43
  • @Lawrence - a quick glance at 'isolation in PHP' leads me to believe that it's more of XSS related question where this is specifically a third party PHP problem. the final answers might be the same, but i think the actual question is significantly different. – JSON Nov 14 '13 at 05:53
  • In regards to what my privileges are. It will be hosted on an my server. I can do whatever I want :) – SomeNorwegianGuy Nov 14 '13 at 07:26
  • more as general thought: PHP Streams http://us2.php.net/manual/en/book.stream.php . directory level restriction of functions (disable_functions/_classes in php.ini) or setting of an environment ( eg runkit: http://www.php.net/manual/en/book.runkit.php) for the 3prty folder. open_basedir php.ini setting. Depends a bit how you would want php code to be run. – Filou Nov 14 '13 at 14:27

2 Answers2

1

Sounds like setting open_basedir for the 3rd party directory would work. This won't keep 3rd party scripts from "knowing" about other 3P scripts, but it would prevent accessing core or any external system files.

K.A.F.
  • 2,277
  • 1
  • 16
  • 17
0

This really depends heavily on what kind of server-side configuration you have setup. Lets take apache for example, your Apache threads are all going to be run as the system user defined in the User directive (usually something like _www, www-data, or apache) found in your httpd.conf file. If your project includes files from your vendor at any point, those will be executed with the same User (thus the same permission level) as the core files, giving them access to read everything.

I believe only way to achieve what you're proposing is a complete division of the core and vendor libraries, manually changing the current user and then executing the vendor libraries as separate executions. The vendors would need to support this kind of interaction. It could get pretty nasty though, and wouldn't recommend this in a production environment (could be manipulated by the vendor libraries if they are malicious):

<?php
$restricted_user = 'vendor';
$user_info = posix_getpwnam($restricted_use);

// change the user before executing the external vendor scripts
posix_setuid($user_info['uid']);
posix_setgid($user_info['gid']);

// run the vendor scripts using exec, shell_exec, system, pass_thru...
system('php /path/to/vendor/script.php');

Generally speaking, it's a bad idea to allow any executable code on your server whose execution patterns you don't trust.

jpschroeder
  • 6,636
  • 2
  • 34
  • 34
  • 1
    Using suPHP (http://www.suphp.org/Home.html) would seem another approach to the same effect (taken from http://stackoverflow.com/questions/5860439/isolation-in-php as commented by Lawrence above) – Filou Nov 14 '13 at 18:13
  • If it is foolable, and not viable for production, its not viable for me. But thanks. – SomeNorwegianGuy Nov 14 '13 at 19:57