Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31917
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain suso.org designates 216.9.132.134 as permitted sender)
Date: Sun, 26 Aug 2007 19:31:47 +0000
To: internals@lists.php.net
Message-ID: <20070826193146.GQ16782@arvo.suso.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.11
Subject: Safe mode being removed in PHP6?
From: mark@suso.org (Mark Krenz)


  First of all I don't want this to sound like a personal attack, its
professional.  I just encountered something that really aggrevates me
about the state of PHP and I want to be heard by the developers.

 I just read through this document,

   http://www.php.net/~derick/meeting-notes.html

 and read the notes on safe_mode and open_basedir. PHP as is, is a real
pain in the ass to lock down completely and it always has been. In fact,
I'd venture to say that its impossible.  And believe me when I say that
I've tried and I'm no slouch.  The only way I can really lock it down is
to use modules like mod_suphp that run the scripts simular to how suexec
works.  But I can't just turn that on for every user on my system
because things like Mediawiki simple URLs don't work right and possibly
other things won't work.  Some developers will not take responsibility
for their programs not working and I'm getting tired of telling my
customers that there are brain dead developers out there writing popular
software.

 The PHP developers trying to shun the problems off to being an Apache
problem or OS problem is irresponsible. If PHP is a module running in
Apache.  What can Apache do?  Maybe I'm missing something here.

  open_basedir is vulnerable to the work around and safe_mode is
vulnerable to other problems that I've notified the developers about.
But removing safe_mode will only make things more unsecure not less.  I
know its a pain in the ass for people, but I think that until the PHP
developers can come up with a 100% secure way to run PHP, they shouldn't
be removing functionality like this.  Otherwise I'm going to have to
stay away from PHP 6.  My security model for websites on Suso is
partially based around safe_mode and other things like suexec and
enforcing restrictive permissions on user's homedirectories and so on.
But take safe mode away and users will be able to execute programs that
can read other user's files.  As simple as writing a program like this:

$arg = "/home/otheruser/www/filewithdbpassword.inc";

$output = "";
exec("/bin/cat $arg", $output);

print $output[0];

  Its pretty trivial to get around the security of open_basedir alone,
and I can't think of a way to prevent this using Apache or filesystem
permissions.  Perhaps there is a way using ACLs or selinux, but of
course this wouldn't work on all systems and I think that is expecting
too much.

  So what is the plan for increasing the security of PHP rather than
decreasing it?  I've been waiting since Apache 2.0 (7 years now) for PHP
to take advantage of things Apache 2.0 offers in terms of being able to
let modules run as the user, but I've seen nothing in this regard.

-- 
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/