From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Viewing Auditd LOG format (RHEL 4 Workstation: 64bit Kernel 2.6.9-67) Date: Tue, 27 May 2008 11:43:46 -0400 Message-ID: <200805271143.46946.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: "McCarthy, John D." List-Id: linux-audit@redhat.com On Tuesday 27 May 2008 10:43:05 McCarthy, John D. wrote: > Is there a way to view/change the Auditd log format so when I view the > logs they are more user friendly to read? Not really. The format option is really to describe any kind of change to the data that the audit daemon might make. raw is the only supported option. But others might in the future be binary or compressed. > I think the auditd.conf file format is FORMAT=RAW, is this the setting and > if so can I change it so my logs are less complicated to read. The design of the audit system is to grab the subject and its credentials and the object and all its permission or security related attributes and send that out as one event. Different hooks in the kernel create a record of what they see as the event occurs. So, it has this kind of fragmented view of subrecords. For example, syscall entry has no idea what the file permissions or inode is of the resolved file. The hook in the file system has no idea what the syscall was. So each part of the kernel contributes its own knowledge about the current event. The idea is just to dump this to disk as fast as possible and rely on data reduction tools to make sense of it. The first program written was ausearch. It has the ability to group the records into an event, scan for particular events, and to interpret numbers to human readable form. But this doesn't give you snapshot or summary information. aureport was the second tool developed to try to boil down this information into something more readable. (Does this one work for you?) Writing that tool made me realize that we really need a standard parser so that anyone can write tools around the audit data. That work took a long time to get right and I think we finally have a full library that can be used to write the next generation of tools. A new program, audit_viewer, was recently released based on the new parser. I see it as the beginning of new tools that people can write to make the audit data more user friendly. So far, no one has really stated what they really want the audit data to look like. So, its the way it is due to no input from people that use it and due to not having had the tools to effectively act upon any suggestions we might have gotten about formatting. So, I think this project is about at the point we can write good tools. We need suggestions about how to present the information. -Steve