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

[John Dennis <jdennis@redhat.com>]

[-- 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 --]