The 1.22 release adds a new configuration variable,
$wgRedactedFunctionArguments, that allows administrators of MediaWiki
installations to designate function arguments that should be redacted
from stack traces. For example:
$wgRedactedFunctionArguments[] = array('User::comparePasswords' =>
array( 0, 1 ) )
This value specifies that whenever the method User::comparePasswords
appears in an exception stack trace, the value of the first and second
arguments are to be redacted, meaning the string 'REDACTED' is
inserted where the argument value would otherwise appear. The case for
this feature was made in
<https://bugzilla.wikimedia.org/show_bug.cgi?id=30714>.
I think that it is a design blunder, and that we should remove it from
MediaWiki. The task of making $wgRedactedFunctionArguments
comprehensive is hopelessly gargantuan. It would require something
like a full trace of the flow of data throughout all of MediaWiki and
its extensions.
The best case scenario is that the feature is not used. The worst case
-- which seems to be materializing, judging by the default value
assigned to it in DefaultSettings.php -- is that it is used with a
short and chronically out-of-date list of obvious suspects, and that
the resultant traces leak private data. This is actually worse than
making no attempt at all to sanitize traces, because it is liable to
mislead and inspire false feelings of confidence.
I think that the proper way to handle low-level operational data like
stack traces is to make it clear that it is liable to contain
sensitive information, and to make no pretense at all of sanitizing
it. If there is a credible need for outputting redacted traces, the
output should exclude *all* values, not just the ones that someone
remembered to configure.
---
"Base access decisions on permission rather than exclusion. This
principle...means that the default situation is lack of access, and
the protection scheme identifies conditions under which access is
permitted. The alternative, in which mechanisms attempt to identify
conditions under which access should be refused, presents the wrong
psychological base for secure system design. A conservative design
must be based on arguments why objects should be accessible, rather
than why they should not. In a large system some objects will be
inadequately considered, so a default of lack of permission is safer.
A design or implementation mistake in a mechanism that gives explicit
permission tends to fail by refusing permission, a safe situation,
since it will be quickly detected. On the other hand, a design or
implementation mistake in a mechanism that explicitly excludes access
tends to fail by allowing access, a failure which may go unnoticed in
normal use. This principle applies both to the outward appearance of
the protection mechanism and to its underlying implementation."
("The Protection of Information in Computer Systems",
http://web.mit.edu/Saltzer/www/publications/protection/Basic.html)
---
Ori Livneh
o...@wikimedia.org
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
