| Re: Sandbox [message #182083 is a reply to message #182082] |
Fri, 05 July 2013 19:20  |
J.O. Aho
Messages: 194
Registered: September 2010
Karma:
|
Senior Member |
|
|
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(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.
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]