From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: [PATCH] Fix acct quoting in audit_log_acct_message()) Date: Tue, 04 Mar 2008 16:21:01 -0500 Message-ID: <47CDBD3D.7030101@redhat.com> References: <47CCC6F0.1090005@redhat.com> <47CD65A3.8020204@redhat.com> <1204654248.12783.32.camel@vespa.frost.loc> <200803041356.19571.sgrubb@redhat.com> <47CDB116.7010007@redhat.com> <1204663403.3216.126.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1204663403.3216.126.camel@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Eric Paris wrote: > Can you show some example of which kernels had one thing and which > kernels another? These are the encoded audit strings in kernel 2.6.24 (Fedora): a[0-9]+ comm cwd data dir exe key msg name new old path These are the encoded audit strings in kernel 2.6.18 (RHEL-5): comm cwd exe key name new ocomm old path This is what audit-1.6.5 checks for: acct cmd comm cwd exe file name path watch This list does not include strings which are not encoded, only those known to be subject to hexadecimal decoding! Absolutely none of the above fields should require special table driven logic in order to read their value as a string. Just to make life interesting I believe some of these field names appear in more than one record type. This is just two OS's. In real deployments a site might be running a much larger set of OS's all emitting audit data and probably not capturing the OS version along with the audit data. Every time we have a new release we compound the problem. Every time a new piece of audit data is added the problem is compounded. Any patch has the potential to modify the audit contents. -- John Dennis