From mboxrd@z Thu Jan 1 00:00:00 1970 From: Karl MacMillan Subject: Re: audit 1.2.7 released Date: Thu, 21 Sep 2006 15:43:50 -0400 Message-ID: <1158867830.28640.97.camel@localhost.localdomain> References: <200609182013.40133.sgrubb@redhat.com> <200609201519.47804.sgrubb@redhat.com> <451195CB.9000909@hp.com> <200609201540.52990.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200609201540.52990.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 On Wed, 2006-09-20 at 15:40 -0400, Steve Grubb wrote: > On Wednesday 20 September 2006 15:26, Paul Moore wrote: > > > I try very hard to not have any memory allocations in the audit system to > > > prevent any possible failure due to fragmentation or leaks. I need to cap > > > the buffer size at something to meet this design goal. > > > > If this buffer limitation results in the loss or partial-loss of an > > audit record is there some notification sent? > > No. > > > This seems like an excellent way for an individual to obscure their actions > > on a system. > > Well, the particular buffer that Amy cited was 128 in size and only for > startup/shutdown messages. It has been increased to 384. The other buffer > that holds the events from syscall, file system, and trusted apps was 8460 > and is now 8970. > There are very few limits on the size of contexts, though, and any heavy use of MLS / MCS categories could make the average context size grow quickly. Granted this is controllable by policy and, presumably, solvable by an admin. Karl