Re: Run-time taint support proposal
| From: | Pierre | 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:"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.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 beI 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.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.