Re: get_field_str() and interpret_field() bug with multi-word fields

John Dennis
2008-08-12T22:37:36Z

[-- Attachment #1.1: Type: text/plain, Size: 2339 bytes --]

Steve Grubb wrote:
> On Tuesday 12 August 2008 17:09:18 John Dennis wrote:
>
>> The fact you can have any combination of kernel, user code, and
>> historical log files is precisely why this need to be fixed ASAP. Why?
>> Because there is no value in being backwards compatible with a data
>> stream you can't read when any of the three components (kernel, user
>> libraries, files) are permuted.
>>
>
> John, you are very wrong here.
I respectfully disagree.
> We are about to role out remote logging for the
> audit system. ... So, in the future you will likely have a RHEL6 machine aggregating RHEL5
> machines.
This is exactly the problem I trying to avoid. Once the log data is
divorced from the user space tools necessary to correctly parse it there
are going to be enormous problems.

Let me be clear, I'm worried about the scenario where an audit log file
was archived from some random system in MegaCorp, then many years later
an auditor investigating MegaCorp decides that log file has critical
information in it. Is MegaCorp going to be able to satisfy the
regulatory requirements to correctly extract the audit data when the
sys-admin who set up the logging left the company years ago, the
information about the system has since been lost, the system has since
been re-installed with a new OS, and no one bothered to archive the
matching version of auparse with the log file?

Don't forget, many auditing regulations require the raw log data to be
preserved, not an interpreted version of the log data. This means one
cannot just run auparse over the file to re-format it prior to archiving
it unless one is willing to store two copies, the raw file and an
interpreted version. People don't want to store two versions of data for
obvious reasons. They want to store the raw data and correctly read it
at any point in the future with one tool. The current scheme does not
satisfy those requirements, nor is it scalable.

I believe it's an absolute requirement that audit log files can be
correctly parsed independent of any external information.

> They will not be happy if they find that they have to upgrade all
> the machines just to do reports. There's no way I'm going to tell people we
> are cutting you off, you have to upgrade.
>

> -Steve
>

--
John Dennis <jdennis@redhat.com>

[-- Attachment #1.2: Type: text/html, Size: 3187 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]