| Re: Sandbox [message #182080 is a reply to message #182079] |
Fri, 05 July 2013 17:33   |
J.O. Aho
Messages: 194
Registered: September 2010
Karma:
|
Senior Member |
|
|
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(at)gmail(dot)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.
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".
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.
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?
--
//Aho
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]