[PATCH] audit: allow unlimited backlog queue

[Richard Guy Briggs]

On 14/01/15, Steve Grubb wrote:
> On Wednesday, January 15, 2014 11:46:54 AM Richard Guy Briggs wrote:
> > On 14/01/15, Steve Grubb wrote:
> > > On Tuesday, January 14, 2014 06:04:32 PM Richard Guy Briggs wrote:
> > > > On 14/01/14, Richard Guy Briggs wrote:
> > > > > Since audit can already be disabled by "audit=0" on the kernel boot
> > > > > line,
> > > > > or by the command "auditctl -e 0", it would be more useful to have the
> > > > > audit_backlog_limit set to zero mean effectively unlimited (limited
> > > > > only
> > > > > by system resources).
> > > > > 
> > > > > These are userspace source code documentation changes in what's going
> > > > > in
> > > > > 
> > > > > upstream.  See:
> > > > >       audit: allow unlimited backlog queue
> > > > > 
> > > > > git://toccata2.tricolour.ca/linux-2.6-rgb.git
> > > > > https://lkml.org/lkml/2013/10/22/356
> > > > > https://www.redhat.com/archives/linux-audit/2013-October/msg00029.html
> > > > 
> > > > And this is a related BZ:
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=999756
> > > 
> > > This patch doesn't make sense in that context either. The problem is
> > > systemd floods the audit system before auditd comes up. This begs the
> > > question of whether auditd is being started early enough.
> > 
> > Or that the queue isn't long enough.
> > 
> > Do you have any specific ideas on getting auditd started earlier?
> 
> It would be explaining to the systemd people what problem we are having and 
> asking for advice or changes to their sequence of what gets started when.
> 
> 
> > > One solution from that bz is to make a boot time config option. Problem
> > > is,
> > > everyone that really cares about audit will have to set that. So that
> > > means
> > > the default should be bumped up. However, the bz mentions that embedded
> > > systems don't like that. So, why not make a compile time config option
> > > that
> > > keeps the current default (64) and server/desktop distributions can make
> > > that 512? You can even provide a boot time config so that people with
> > > really busy systems can make it bigger if they choose.
> > 
> > There is a boot config option that has just been added to do that too:
> > 	audit: add kernel set-up parameter to override default backlog limit
> > 
> > It will be upstream in 3.13.
> > 
> > Eric and I discussed bumping up the default.  I would have liked to have
> > seen somewhere between 320 and 512, but that default would make the
> > embedded folks unhappy and I don't really want to get into the more
> > complex idea of having it guess what type of system it is trying to
> > configure to give a smaller number for embedded systems (which aren't
> > all small) and bigger ones to servers (which aren't all big).
> 
> What about making it a compile time choice in the kernel config? I suggested 
> making a compile time option, distributions can bump that up to 512, the 
> default is enough and it can be tuned. Embedded can make the default whatever 
> they want, too.

Eric and I had discussed that too, and I understand there is
considerable pushback to adding to kconfig, so that option would be
harder to get accepted.

> -Steve

- RGB

--
Richard Guy Briggs <rbriggs at redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545