Re: [PHP-DEV] why the damn phpinfo() is so talkative? + answers From: Jason Greene (usrgre-php <email protected>)
Date: 10/20/00

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 <email protected>>
To: "Andi Gutmans" <andi <email protected>>
Cc: <teo <email protected>>; <php-dev <email protected>>
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 <email protected>
> For additional commands, e-mail: php-dev-help <email protected>
> To contact the list administrators, e-mail: php-list-admin <email protected>
>

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>