[PATCH] audit: allow unlimited backlog queue

[PATCH] audit: allow unlimited backlog queue

[Richard Guy Briggs]

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).

Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---

Steve,

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

 trunk/docs/auditctl.8 |    2 +-
 trunk/src/auditctl.c  |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/trunk/docs/auditctl.8 b/trunk/docs/auditctl.8
index 0ee1a83..dbb911d 100644
--- a/trunk/docs/auditctl.8
+++ b/trunk/docs/auditctl.8
@@ -8,7 +8,7 @@ The \fBauditctl\fP program is used to control the behavior, get status, and add
 .SH OPTIONS
 .TP
 .BI \-b\  backlog
-Set max number of outstanding audit buffers allowed (Kernel Default=64) If all buffers are full, the failure flag is consulted by the kernel for action.
+Set max number of outstanding audit buffers allowed (Kernel Default=64) If all buffers are full, the failure flag is consulted by the kernel for action.  Setting this to "0" (which is dangerous) implies an unlimited queue, limited only by system resources.
 .TP
 \fB\-e\fP [\fB0\fP..\fB2\fP]
 Set enabled flag. When \fB0\fP is passed, this can be used to temporarily disable auditing. When \fB1\fP is passed as an argument, it will enable auditing. To lock the audit configuration so that it can't be changed, pass a \fB2\fP as the argument. Locking the configuration is intended to be the last command in audit.rules for anyone wishing this feature to be active. Any attempt to change the configuration in this mode will be audited and denied. The configuration can only be changed by rebooting the machine.
diff --git a/trunk/src/auditctl.c b/trunk/src/auditctl.c
index 325b0a7..5b544a1 100644
--- a/trunk/src/auditctl.c
+++ b/trunk/src/auditctl.c
@@ -107,7 +107,7 @@ static void usage(void)
      "    -a <l,a>            Append rule to end of <l>ist with <a>ction\n"
      "    -A <l,a>            Add rule at beginning of <l>ist with <a>ction\n"
      "    -b <backlog>        Set max number of outstanding audit buffers\n"
-     "                        allowed Default=64\n"
+     "                        allowed. Default=64 Unlimited=0(dangerous)\n"
      "    -c                  Continue through errors in rules\n"
      "    -C f=f              Compare collected fields if available:\n"
      "                        Field name, operator(=,!=), field name\n"
-- 
1.7.1

Re: [PATCH] audit: allow unlimited backlog queue

[Richard Guy Briggs]

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).
> 
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> 
> Steve,
> 
> 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

>  trunk/docs/auditctl.8 |    2 +-
>  trunk/src/auditctl.c  |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/trunk/docs/auditctl.8 b/trunk/docs/auditctl.8
> index 0ee1a83..dbb911d 100644
> --- a/trunk/docs/auditctl.8
> +++ b/trunk/docs/auditctl.8
> @@ -8,7 +8,7 @@ The \fBauditctl\fP program is used to control the behavior, get status, and add
>  .SH OPTIONS
>  .TP
>  .BI \-b\  backlog
> -Set max number of outstanding audit buffers allowed (Kernel Default=64) If all buffers are full, the failure flag is consulted by the kernel for action.
> +Set max number of outstanding audit buffers allowed (Kernel Default=64) If all buffers are full, the failure flag is consulted by the kernel for action.  Setting this to "0" (which is dangerous) implies an unlimited queue, limited only by system resources.
>  .TP
>  \fB\-e\fP [\fB0\fP..\fB2\fP]
>  Set enabled flag. When \fB0\fP is passed, this can be used to temporarily disable auditing. When \fB1\fP is passed as an argument, it will enable auditing. To lock the audit configuration so that it can't be changed, pass a \fB2\fP as the argument. Locking the configuration is intended to be the last command in audit.rules for anyone wishing this feature to be active. Any attempt to change the configuration in this mode will be audited and denied. The configuration can only be changed by rebooting the machine.
> diff --git a/trunk/src/auditctl.c b/trunk/src/auditctl.c
> index 325b0a7..5b544a1 100644
> --- a/trunk/src/auditctl.c
> +++ b/trunk/src/auditctl.c
> @@ -107,7 +107,7 @@ static void usage(void)
>       "    -a <l,a>            Append rule to end of <l>ist with <a>ction\n"
>       "    -A <l,a>            Add rule at beginning of <l>ist with <a>ction\n"
>       "    -b <backlog>        Set max number of outstanding audit buffers\n"
> -     "                        allowed Default=64\n"
> +     "                        allowed. Default=64 Unlimited=0(dangerous)\n"
>       "    -c                  Continue through errors in rules\n"
>       "    -C f=f              Compare collected fields if available:\n"
>       "                        Field name, operator(=,!=), field name\n"
> -- 
> 1.7.1
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

- RGB

--
Richard Guy Briggs <rbriggs@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

Re: [PATCH] audit: allow unlimited backlog queue

[Steve Grubb]

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.

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.

Making 0 mean unlimited won't help embedded systems.

-Steve

Re: [PATCH] audit: allow unlimited backlog queue

[Richard Guy Briggs]

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?

> 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).

> Making 0 mean unlimited won't help embedded systems.

This is not trying to solve that problem.

> -Steve

- RGB

--
Richard Guy Briggs <rbriggs@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

Re: [PATCH] audit: allow unlimited backlog queue

[Steve Grubb]

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.

-Steve

Re: [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@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

Re: [PATCH] audit: allow unlimited backlog queue

[Steve Grubb]

On Wednesday, January 15, 2014 12:12:28 PM Richard Guy Briggs wrote:
> > > 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.

So how does making the backlog value of 0 be unlimited solve the problem?

-Steve

Re: [PATCH] audit: allow unlimited backlog queue

[Richard Guy Briggs]

On 14/01/15, Steve Grubb wrote:
> On Wednesday, January 15, 2014 12:12:28 PM Richard Guy Briggs wrote:
> > > > 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.
> 
> So how does making the backlog value of 0 be unlimited solve the problem?

It doesn't directly, but is related.  The patch that allows the kernel
command line to be set with the value does this.  It also helps for
transients.  The documentation in the userspace patch also then becomes
consistent with the kernel command line behaviour.

> -Steve

- RGB

--
Richard Guy Briggs <rbriggs@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

Re: [PATCH] audit: allow unlimited backlog queue

[Gao feng]

On 01/15/2014 06:59 AM, 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).
> 
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> 

Acked-by: Gao feng <gaofeng@cn.fujitsu.com>
Thanks!

Re: [PATCH] audit: allow unlimited backlog queue

[Steve Grubb]

On Tuesday, January 14, 2014 05:59:16 PM 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).

I don't see a useful purpose to this.

-Steve

Re: [PATCH] audit: allow unlimited backlog queue

[Richard Guy Briggs]

On 14/01/15, Steve Grubb wrote:
> On Tuesday, January 14, 2014 05:59:16 PM 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).
> 
> I don't see a useful purpose to this.

That's up to you.  On your side it is a documentation question.  It is
already implemented in the kernel.  The rationale I thought was fairly
clear.  The flexibility is there.  A warning would be useful.

> -Steve

- RGB

--
Richard Guy Briggs <rbriggs@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