Re: Comments on PHP security
| From: | Arnold Daniels | Date: | Wed, 17 Jan 2007 12:38:57 +0000 |
| Subject: | Re: Comments on PHP security | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-27499@lists.php.net to get a copy of this message | ||
Hi again,
Yes we can share it with the world, but first it should be reviewed by others to see if we haven't missed anything which makes the system less secure instead of more. Also the source code is currently really dirty and specified on our situation (to little to config, mod_diffpriv also does mass virtual hosting, etc.).
Please send me an e-mail, if you would like to review it and I'll send you the source code. Again, please note that you need to patch your kernel for it, so you need to do it on some test server or a virtual machine.
Best regards,
Arnold
PS. The line in my previous mail should read: "We (not me) have written a kernel patch to allow switching *of the user* of the current processes (much like sudo) and a matching apache module.". But I guess you understood.
Alain Williams schreef:
On Wed, Jan 17, 2007 at 12:45:37AM +0100, Arnold Daniels wrote:Hi, First of all I admit I'm no PHP security expert or PHP internals expert or anything, so please don't flame me if I say something stupid. Wouldn't simply adding a flag to allow url's (which includes all '*://' streams), in functions that opens streams be enough? For example: fopen($file, 'r') and fopen($url, 'ru') and fopen('php://output', 'ru'). To my opinion, using '*://' streams is an advanced feature. Developers who are using that, should be able to make sure no urls are opened. Again, just an idea.Brilliant. The only thing that need be added is a config var to control the default behaviour - which should be 'don't allow'. Doesn't fix everything (eg includes), but it is a good start. Note that: allow_url_fopen is not the same thing as that does not allow the program to specify when it wants it.Last, I'm a software developer at a shared hosting company. To my opinion, making sure that users don't touch other people's files, does not belong in the PHP layer. With other apache modules you can do nasty thing as well. We (not me) have written a kernel patch to allow switching of the current processes (much like sudo) and a matching apache module. Since the privileges only allow the user or group to access the file, linux does the rest. An other solution is to start PHP as cgi under the correct user, but other things will never be really save.Care to share that with the world ?