Re: why the damn phpinfo() is so talkative? + answers

CGI can be easily secured by using a customized suexec that chroots to a sandbox for sure. However, my goal, which I am almost complete in, is a module version with the same security. I have hacked php to perform something similar in runtime, however the implementation is just a hack. I am currently working on another feature that would block a list of environment variables, and am almost complete. I am targetting the php_variables.c function php_import_environment_variables, and the getenv function call As for programs being ran on the system, safe mode does not allow this. As for badly written modules, I do not see any that I am using that would display environmental information. I do agree that ppl should secure the environment as best as possible but, I think that you can never have too much security, and the env -i does not work in all environments, becauese apache may require certain variables (LD_LIBRARY_PATH) - ex chilisoft. Also, there is a possibility that systems admin restarts the service on his web account, not knowing that env -i is crucial. After this, I would like to begin on implementing a better version of the hack that locks users into a virtual directory. I posted a message called webhosting enhancements(10/13/2000), where I talk about the problems I have had in building a safe hosting level php in module version I really would like to see php offering a secure programming environment, it would greatly increase php's usage in hosting platforms. -Jason ----- Original Message ----- From: "Kristian Köhntopp" <kk@netuse.de> To: "Andi Gutmans" <andi@zend.com> Cc: <teo@digiro.net>; <php-dev@lists.php.net> Sent: Friday, October 20, 2000 3:51 AM Subject: Re: [PHP-DEV] why the damn phpinfo() is so talkative? + answers > Andi Gutmans wrote: > > I think it should be done on the user level like you > > pointed out below. We could put such a suggestion in > > the manual (to run with env -i). > > This is by far not enough. If you are going to > put a chapter on safe deployment policies into > the manual, you need to differentiate along > Windows and Unix systems, and along CGI and > module versions of PHP. You'd want to talk about > properties and limitations of safe_mode, about > Unix process limits such as setrlimit and chroot, > about typical additional safeguards for system > security such as "env -i", "suexec replaced by > sbox, using chroot", about the need to differentiate > anonymous root (http docroot) vs. authenticated root > (ftp chroot, being one level ABOVE docroot in order > to make directories without unauthenticated access > available) and the need to store logfiles and > configuration files outside of docroot. > > Also, there should be talk about secure PHP programming, > touching not only system level security as above, > but also application level security. The section should > be talking about control flow analysis, tainted variables, > input validation with regexp and other stuff, avoiding > register_globals = On in order to facilitate that, writing > programs in PHP normal form, event driven programming > and validation methods and finally designing secure and > ergonomic URLs for your application access... > > You could, on the other hand, just buy the book by Till > and Tobias, which already covers most of this. > > Kristian > > > -- > Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel > Tel: +49 431 386 436 00, Fax: +49 431 386 435 99 > Using PHP3? See our web development library at > http://phplib.netuse.de/ > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >