From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: Cooked audit log format Date: Mon, 12 May 2008 12:12:34 -0400 Message-ID: <48286C72.3020106@redhat.com> References: <482767E0.10506@redhat.com> <200805121043.17906.sgrubb@redhat.com> <48285C0C.5070809@redhat.com> <200805121119.46856.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0111919391==" Return-path: In-Reply-To: <200805121119.46856.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============0111919391== Content-Type: multipart/alternative; boundary="------------090900000905040701060107" This is a multi-part message in MIME format. --------------090900000905040701060107 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Steve Grubb wrote: >> Strings should be either always hex encoded, or always escaped >> (preferably the latter). >> > > The issue that always dominates any thinking about the audit system is how to > save diskspace. So, whenever a string has no naughty characters, we let it go > as is. If the string contains something that will confuse the parser or do > other bad things, we encode the string such that the parser cannot be > confused. But we only do that on demand because the majority of strings are > well-behaved. > This is not a true statement, unless the kernel has been patched recently the handling of strings is seriously broken, a fact which has been pointed out numerous times. It is also not true that parser cannot be confused by the string format, also pointed out several times. It should also be a goal that libraries other than auparse be capable of parsing audit strings. It should also be a goal that correct parsing of audit logs not be dependent on specific kernel versions. The extra bytes in question would likely never exceed .01% of total file size thus concerns about the extra bytes needed to properly escape a string hogging disk space should not advanced in 2008 with large disks and high bandwidth networks, reliable parsing trumps 1970's optimization concerns. -- John Dennis --------------090900000905040701060107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Steve Grubb wrote: 
Strings should be either always hex encoded, or always escaped
(preferably the latter).
    

The issue that always dominates any thinking about the audit system is how to 
save diskspace. So, whenever a string has no naughty characters, we let it go 
as is. If the string contains something that will confuse the parser or do 
other bad things, we encode the string such that the parser cannot be 
confused. But we only do that on demand because the majority of strings are 
well-behaved.
This is not a true statement, unless the kernel has been patched recently the handling of strings is seriously broken, a fact which has been pointed out numerous times. It is also not true that parser cannot be confused by the string format, also pointed out several times. It should also be a goal that libraries other than auparse be capable of parsing audit strings. It should also be a goal that correct parsing of audit logs not be dependent on specific kernel versions.

The extra bytes in question would likely never exceed .01% of total file size thus concerns about the extra bytes needed to properly escape a string hogging disk space should not advanced in 2008 with large disks and high bandwidth networks, reliable parsing trumps 1970's optimization concerns.
-- 
John Dennis <jdennis@redhat.com>
--------------090900000905040701060107-- --===============0111919391== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0111919391==--