Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "J.O. Aho" Newsgroups: comp.lang.php Subject: Re: Sandbox Date: Fri, 05 Jul 2013 21:20:02 +0200 Lines: 133 Message-ID: References: <7a68d12f-b9f2-4367-b373-f6be14b9994b@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net NXweyiaXzi2Bd9cCO7+ThQWhFeWN857fi0wSNFrAa57Mx7WDBi Cancel-Lock: sha1:FIJfUVyvf8FJjKXebmPQt1sEUpI= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 In-Reply-To: Xref: csiph.com comp.lang.php:10036 On 05/07/13 21:07, Jerry Stuckle wrote: > On 7/5/2013 1:33 PM, J.O. Aho wrote: >> On 05/07/13 18:53, Jerry Stuckle wrote: >>> On 7/5/2013 12:24 PM, J.O. Aho wrote: >>>> On 05/07/13 14:25, Jerry Stuckle wrote: >>>>> On 7/5/2013 7:38 AM, sanjayrathod273@gmail.com wrote: >>>>>> HEy guys Help me >>>>>> >>>>>> I want to use sandbox for my site's security. below is the link of >>>>>> method which i want to use >>>>>> http://php.net/manual/en/runkit.sandbox.php. >>>>>> >>>>>> but when i am run the code of that page it says sandbox class not >>>>>> defined. >>>>>> so anyone can guide me through this step by step. >>>>>> Please help me my site has down due to hacking. i want to use for >>>>>> this >>>>>> site >>>>>> http://web.guru99.com/demo-editor-php/ >>>>>> >>>>> >>>>> Look at the documentation - you need the runkit PECL class. But that >>>>> has not been updated for seven years and will not compile with PHP >>>>> versions > 5.2. It looks like you're out of luck. >>>>> >>>>> But then while I think what you're trying to do is admirable, I don't >>>>> think you'll be able to stop hacking without pretty much crippling >>>>> your >>>>> users. Anyone developing (or learning) PHP should have their own >>>>> development environment, anyway. >>>>> >>>> >>>> There are other options to "sandbox" the users, suExec will give you >>>> some capabilities and then on you can also run the apache in a chroot >>>> environment. This way you can limit the access through the webserver to >>>> the rest of the server environment and limit the sites from accessing >>>> each others data. I usually apply the suhosin to the php and set a bit >>>> limitation that way too. Doing all that you need of course a Linux/Unix >>>> server. >>>> >>> >>> Yes, but look at his site. He's trying to create an online PHP executor >>> for people to use. Your suggestions won't help there - it's impossible >>> to use them to limit access to the files from user-developed code >>> (evidently executed with eval()) while still making it available to the >>> installed code. >> >> *nods* >> >>> And limiting things like file functions in his php.ini file will not >>> only limit the functions for user-developed code, but for the code on >>> the site itself. >> >> yeah, you are right, but just let us play things a little bit before >> giving up. >> >> 1. If we start with running the apache in a chroot, we eliminate the >> access to system files. >> > > True, but giving the Apache user very limited rights by itself would > prevent access to system files (but not other website files, of course). > >> 2. Then we run the suExec for the site and php with suhosin, to make >> things a little bit safer in the environment which will be "executing >> the code". >> > > This would definitely make things a lot safer. But you'd still have to > have at least the PHP script being executed available. There doesn't > need to be a lot in that page, however, and careful programming (i.e. no > passwords, no other file accesses, etc.) would make it safe even if the > code was exposed. > >> 3. Instead of using eval to run the user imputed code, we use fpm to >> execute it and set the fpm to use another php.ini than the suExec >> environment Running the fpm in it's own nested chroot, will prevent it >> from accessing those files in the general apache chroot. >> > > Hadn't though about this. It could easily work - i.e. create a page on > the fly from the user's code then execute that page. Permissions might > be a problem, but could be worked out, I guess. > >> Of course this would require a custom made PHP page to handle a such >> setup, but could in theory work, but should be well tested before >> releasing to the wide world web. >> >> Any thoughts about this, or do you see a flaw in my thought? >> > > No obvious flaws, anyway. I guess the biggest part would be he'd need > his own server or VPS as these would require changes to the PHP > executable which a shared host wouldn't be interested in making. Of course, and if there would be a shared host who would be prepared to do so much for a customer, I think I would switch to another safe one, for I think a shared host who does as all their customers want would have a lot of security issues. > Offhand, I'd say it could work, but I'd have to think about it a lot > more, and play with it. But it's not interesting enough to me to spend > a lot of time on it. Same for me, just a theoretical though of a possibility to do it. > A great idea, though. Thanks :) On 05/07/13 20:23, Denis McMahon wrote: > On Fri, 05 Jul 2013 19:33:30 +0200, J.O. Aho wrote: >> Any thoughts about this, or do you see a flaw in my thought? > > I don't know enough to comment generally on your suggestions - but I > go with Jerry's premise that anyone developing php should have their > own dev platform, it's not that hard to set up wamp / lamp out of the > box on your system, or in a vm, or for that matter on a free aws host > (although the memory limit on the latter might be an issue?). If you are going with Suhosin, then wamp is out of the question, it only works on Linux/Unix, don't think it even works on aamp. The other parts may. Memory print shouldn't be much more than for a standard setup, but sure the fpm would take up some of the memory and make less things left for the users script. -- //Aho