httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: [PATCH] mod_log_forensic security considerations
Date Sat, 09 Jun 2012 04:00:03 GMT
On 6/8/2012 10:55 AM, Daniel Gruno wrote:
> On 06/08/2012 05:45 PM, Joe Schaefer wrote:
>> Well not quite, we'd still have had a problem with storing and
>> archiving those logs even if we hadn't made them available to
>> committers, because they violate our password retention policies.
> My point was, that it should fall upon us to add a filter if we want to
> archive our logs with certain forensic details omitted, and not be a
> default assumption that people want forensic logs but not this, this and
> that stored.
> Thus, I'd be more in favor of either piping it through a filter or
> adding something like ForensicLogFilter option [,option...]

Should the support/check_forensic script (which fails to install into bin/,
fwiw) be given the magic to purge all obvious credential by default, and
only retain them in the result set if we --disclose-everything (or some
similar semantic?)  It might help reinforce how delicate this data is.

OTOH, I have the same fundemental objection to this patch as I do to
applying crazy logic to purge crash dumps of any potential p/w leakage.
At any given time, the socket traffic and the httpd process itself are
privy to all sorts of security details not available to mere mortals.
Anyone with root can intercept this information.

People need to grok the responsibilities of root, and grok the dangers
of core files and forensic crash and traffic analysis.  We can document
the heck out of these features, and their dangerous side effects, but
treating mod_log_forensic as 'just a logging tool' is foolish.

View raw message