On May 11, 2002 06:56 pm, Chand wrote: > The solution we've chosen is to have a cgi php binary instead of a > module for security stuff. The main reason to do so was to have the > user-created file have the user's uid. We had to suid the php binary and > setuid() the process to the script's uid, of course. This seemed like a > good security trouble-keeper (I know some people will say that setuid > scripts and security in the same sentence usually ain't a good > mix'n'match but .. :) ) since this let the filesystem take care of file > permissions which seemed to me the most secure way, Ain't it ? > Maybe the Open_basedir solution is a better one although i like the idea > of files really owned by the user and not only "virtually". The drawback > on the cgi php binary is performance. We have lotsa trouble with php cgi > binary not dying after the max_execution_time and stayin' alive on the > machines. So we have to terminate them frequently. This has been > reported I think a while back and said to be solved but looks like we > have an environment that's unique in terms of number of requests per > second and load averages, and that not a lot of people can use to test. > So people might have the "dead binaries sleeping around" bug solved, but > we don't.
As far as security is concerned this is probably the best approach, IMHO. Because by running PHP as this user you can use various OS kernel tools such as LIDS or GrSecurity to set limits of what each user can do and how many resources they can consume. > > Ilia, the scripts you talk about that eat up process, cpu, file pointers > etc are very interesting, we've already gone against most of them except > for the file handlers Attack. Never had that but I think i'm gonna talk > about this with our NOC team cause it could be a very big issue now > that's it's in the open :) There are other ways to cause problems with PHP, we could probably go on for days documenting each way someone could use PHP to cause a problem on a server. Here is yet another example: <?php sleep(time()); ?> of <?php while(1) usleep(time()); ?> Now the script will sleep indefinately ignoring the set_time_limit parameter. This webserver thread is now in sleep mode for virtually forever, by repeatedly accessing such a script and attacker can prevent the webserver from serving actual web pages since all threads will be asleep. But this is the nature of any programming/scripting language it allows you do can do things with it :P The ultimate bottom line is that if you do not trust your users to use the tools they are given appropriately then you shouldn't put those tools in their hands. > > Seriously, i've been surprised as to how low was the number of people > trying to hack our system thru PHP. I was really afraid it would far > worse, but this might not be the case everywhere, and we still have to > be vigilant about all that security stuff. > I too think that safe_mode is not a good thing and that open_basedir > seems better and more secure. > > I'm willing to help on a PHP-ISP-Howto document even though but since > i've never done such a thing, i'm not sure i can really do something > good, Plus we might not have taken the best way of doing things around > here. If anybody has comments and or solutions, I'm interested. > > Later > Chand -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
