Hello Wietse, Wednesday, October 3, 2007, 2:35:33 AM, you wrote:
> Changing E_WARNING into E_ERROR causes execution to terminate, as > one would expect. These and other settings can appear in php.ini, > on the PHP command line, or they can be made with ini_set() calls > in the application itself. Sounds like a pretty good solution to me. > Current status > -------------- > My plan is to release something in the next few days, and to go > through a several iterations while adjusting the course based on > the feedback I receive. > The performance is good: the overhead for "make test" is within the > measurement error of 1-2% (when comparing user-mode CPU time). I > do realize that a portion of the total "make test" time is spent > in non-PHP processing, but with the current numbers it doesn't > really matter if taint overhead is 1% or 2%. If someone has a > better "macro" benchmark, then of course I'm interested. > Although the code is still green, its present form already shows > potential to do things like labeling privacy sensitive data (social > security or credit card numbers) and preventing such data from > flying out the window via HTML web pages. ~2% sounds even better to me. > Low-level implementation > ------------------------ > - TC_MYSQL: > - By default, data with this bit is not allowed in mysql_query() > (parameter: taint_checks_mysql). This requirement is not > enforced with the default setting of taint_error_level = 0. > - The mysql_real_escape_string() function produces output without > this bit. > - By default, this bit is set on all data from the web (parameter: > taint_marks_egpcs), from DBMS (parameter: taint_marks_dbms) or > elsewhere (parameter: taint_marks_other). > - TC_MYSQLI: > - Like TC_MYSQL, except this one is for the mysqli_query() API. > The TC_MYSQLI bit is removed with mysqli_real_escape_string(). Couldn't we do a general SQL thing here? Or at leat a small set of different SQL behaviors to capture all databases we support? However we should at least have a verison that works for PDO/ > - TC_SELF: > - By default, data with this bit cannot be used for internal > control operations such as eval, include, as file name argument, > as network destination, or in other contexts where someone could > take away control from the application (parameter: > taint_checks_self). This requirement disappears with > taint_error_level = 0. > - I haven't yet implemented a dedicated conversion function; > to shut up the warnings, this data needs to be marked as > "safe" with a low-level untaint($foo, TC_SELF) call. > - By default, this bit is set on all data from the web (parameter: > taint_marks_egpcs). To me this sounds more like TC_PHP, TC_SELF just doesn't sounds right. > - TC_USER1, TC_USER2: These are labels that an application can set > on specific data. For example, it could set these bits when credit > card or social security numbers come out of a database. The > taint_checks_html policy for HTML output (see above) would then > be configured to disallow data with not only with the TC_HTML > property, but also with TC_USER1 or TC_USER2. Obviously some > polished user interface would need to be built on top of this to > make application-defined attributes usable. > Taint propagation policy > ------------------------ > While adding taint propagation I found that a lot of PHP source > code fails to use the official macros when initializing a zval. In > these cases I added another line of code to initialize the taint > bits by hand. Also, more internal documentation (other than empty > man page skeletons) could have reduced development time significantly. Right. The same is the problem with the GC patches. Once again I think we should disallow all direct access to zval members by inserting different prefixes to zval members. That way wrong usage would make all other compiles fail. So you'd just need to check whether debug and non debug works and be safe. Another approach is to hide the actual zval struct and only provide access functions. But that is slower. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
