|
|
| Re: Sandbox [message #182077 is a reply to message #182076] |
Fri, 05 July 2013 12:25   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sandbox [message #182078 is a reply to message #182077] |
Fri, 05 July 2013 16:24 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
--
//Aho
|
|
|
|
| Re: Sandbox [message #182079 is a reply to message #182078] |
Fri, 05 July 2013 16:53 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
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.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| 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: 0
|
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
|
|
|
|
| Re: Sandbox [message #182081 is a reply to message #182080] |
Fri, 05 July 2013 18:23 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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?).
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: Sandbox [message #182082 is a reply to message #182080] |
Fri, 05 July 2013 19:07 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
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
==================
|
|
|
|
| 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: 0
|
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
]