| Re: Sandbox [message #182082 is a reply to message #182080] |
Fri, 05 July 2013 19:07   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
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(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.
>
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.
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.
A great idea, though.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]