Re: Run-time taint support proposal

From: Date: Tue, 19 Dec 2006 16:50:04 +0000
Subject: Re: Run-time taint support proposal
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-27112@lists.php.net to get a copy of this message
Hello, On 12/19/06, Robert Cummings <robert@interjinn.com> wrote:
On Tue, 2006-12-19 at 17:35 +0100, Pierre wrote: Hello, On 12/19/06, Wietse Venema <wietse@porcupine.org> wrote:
Zeev Suraski:
Following up on an earlier suggestion in this thread, I could see at least three modes of operation: 1) Disabled. The default setting. 2) Audit mode. Report perceived problems to logfile. This can be
    used by developers to catch bugs, and by deployers for quality
    assessment (but developers please don't start screaming yet).
3) Enforcement mode. Don't allow execution past a perceived problem.
I do not think a taint mode is a good thing however to reject this need would be a mistake. But there is a huge difference between a taint mode for the developers or the audit team and something that _will_ be enabled in many ISP, an enforcement mode. I'm "strongly" opposed to add this mode. In a previous post Pierre I suggested to prevent ISPs from thinking this does anything for them that it should be configurable via PHP_INI_ALL. So even if an ISP enabled mode 3, a developer can set it themself right in their source code. Since taint checking is necessarily a run time problem, there's no reason not to allow disabling it via ini_set(). This would ensure that developers would never be put up against the wall of frustration so often encountered by safe mode restrictions.
"disable_functions ini_set, error_reporting" and you are out. And yes, I saw that... The only way to prevent a mode 3 is to do not implement it.

« previous php.internals (#27112) next »