From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Schaufler Subject: Re: missing avc message field names Date: Tue, 30 Jan 2007 10:45:20 -0800 (PST) Message-ID: <490935.83298.qm@web36607.mail.mud.yahoo.com> References: <45BF7AFE.1000701@tresys.com> Reply-To: casey@schaufler-ca.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l0UIjRlX001003 for ; Tue, 30 Jan 2007 13:45:28 -0500 Received: from web36607.mail.mud.yahoo.com (web36607.mail.mud.yahoo.com [209.191.85.24]) by mx1.redhat.com (8.13.1/8.13.1) with SMTP id l0UIjQJD000548 for ; Tue, 30 Jan 2007 13:45:26 -0500 In-Reply-To: <45BF7AFE.1000701@tresys.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: Joshua Brindle Cc: linux-audit@redhat.com, selinux@tycho.nsa.gov List-Id: linux-audit@redhat.com --- Joshua Brindle wrote: > This is fairly off topic here (selinux list) but I > agree with Karl. As a=20 > recovering admin I think I can say that admins > expect to be able to use=20 > various unix utilities to inspect log files, > particularly tail -f. While=20 > I'm all for applications putting their data in > private data formats and=20 > using tools and libraries to inspect them I think it > is generally=20 > considered that everything in /var/log is fair game > to inspect with=20 > anything available on systems (including perl, > python, sed, awk, tail,=20 > grep, etc). >=20 > You will certainly be rubbing most admins the wrong > way by forcing them=20 > through a different interface that won't support > some common commands=20 > like tail -f. >=20 > There are probably hundreds of utilities that look > through these files=20 > as well, what is going to happen when people try to > add audit.log to a=20 > log watcher that emails logs to them? Huge binary > dumps in email are=20 > going to make people turn off the audit daemon, not > modify their apps to=20 > use different tools/libraries. Based on the Unix experience I find myself agreeing with this assessment. Binary (or compressed) audit logs don't get read very often. A mechanism like audit_filters(5) from Irix makes the problem more manageable, but the truth is that humans like their information human readable. Disk space used to be a major problem, and I/O bandwidth still is (you can overwhelm any system with too much audit no matter how optimal your audit data) but the cost of translation-on-read is going to stop most humans from ever doing it. Casey Schaufler casey@schaufler-ca.com