Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31918
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender)
Message-ID: <46D1ED8A.2060302@zend.com>
Date: Sun, 26 Aug 2007 14:15:54 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark Krenz <mark@suso.org>
CC:  internals@lists.php.net
References: <20070826193146.GQ16782@arvo.suso.org>
In-Reply-To: <20070826193146.GQ16782@arvo.suso.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Safe mode being removed in PHP6?
From: stas@zend.com (Stanislav Malyshev)

>  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

No more and no less than any other scripting language, I'd say. And the 
reason for that - it should be done on the OS level, not on the language 
level. OS possesses the capability and created with exactly this purpose.

> 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

I'd attempt some solution involving FastCGI. I think "pretty urls" 
should still work with that, though this needs some checking.

>  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.

Apache can't do much. OS should do it. Now, how to make OS do it there 
you can have a number of solutions, starting with different user IDs and 
up to using things like AppArmor and SELinux.

> But removing safe_mode will only make things more unsecure not less.  I

Removing safe_mode is recognition of un-feasibility of solving this 
problem in PHP context. PHP uses dozens of external libraries, which are 
very hard to control on the level of PHP. Because of that, PHP is not on 
the level which is necessary to provide user-based security - it's too 
high-level.

> 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

Having security solution that works in 90% of the code is no better than 
not having any. Actually, it's worse since some people may mistakenly 
rely on that 90% as if it were 100% and thus neglect to look at the real 
security solutions, leaving the system as vulnerable as if they had no 
security at all.

> 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.

Unfortunately, Apache never really supported running multipe-user 
servers on single Apache instance.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com