On Tue, Jun 29, 2004 at 02:23:31PM +0100, Joe Orton wrote: > On Mon, Jun 28, 2004 at 04:07:30PM -0600, Jason Aeschilman wrote: > > Why is PHP insecure by default on FC1? Is it because it's not for > > production use? It uses a php.ini that is only suited for development, not > > production use. I ended up grabbing the "php.ini-recommended" file from the > > official release of PHP-4.3.6 and made a couple Fedora-related changes to it > > (diff helped out here). > > The php.ini in Fedora Core 2 is based on php.ini-recommended rather than > the development defaults. The differences are not really that > significant, and I don't see which changes matter to "security"; can you > explain why you say "insecure by default"? I have no idea what the initial poster intended but all scripting and programming languages are 'insecure' in that they can do stuff. One important php problem is how it acts in a multi user context without additional support from the OS. (The most common situation for this is in Apache (httpd).) Since the web server's use of php is little different than the use a user might put it to in the context of a scripting language there is an interesting trade off in how it should be configured. Sadly there are a number of applications (squirrel mail comes to mind) that want to use php options that are not good choices on a web site where php is used for other purposes. If a web site has one and only one programmer this is not a problem. But if this same site permits multiple programmers on multiple virtual domains it can quickly become a problem that one user can look over the shoulder of another site and perhaps see or do things that are undesired. Java by design has some tricks to help here and is a better programming language and ENVIRONMENT to this end. IMO, All of this will improve as people match the mechanisms that SELinux provides to parts of this problem, but defaults will not cover this topic. The important point in the comments is that the php.ini file is designed for the development of php script. The developer must design security into the application. Well designed applications should be fine with the defaults (YMMV) Summary: The defaults for php are not too bad for a single owner, simple host/server. More complex things need changes but no set of defaults will address this issue short of making things impossible for all (example: chmod -x /usr/bin/php ;-) ). RTFM cgi, exec(). Parser Warnings: warning good undefined warning bad undefined warning policy undefined -- T o m M i t c h e l l /dev/null the ultimate in secure storage.
