[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhQsVFY1LAakAUUCBZw6nmSy0-eoFrhQgVQrkqgAsWVGhQ@mail.gmail.com>
Date: Mon, 28 Jan 2019 09:19:36 -0500
From: Paul Moore <paul@...l-moore.com>
To: "Sverdlin, Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@...ia.com>
Cc: Paul Moore <pmoore@...hat.com>,
"linux-audit@...hat.com" <linux-audit@...hat.com>,
Richard Guy Briggs <rbriggs@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] audit: always enable syscall auditing when supported and
audit is enabled
On Mon, Jan 28, 2019 at 4:04 AM Sverdlin, Alexander (Nokia - DE/Ulm)
<alexander.sverdlin@...ia.com> wrote:
> Hello Paul,
>
> On 08/12/2015 17:42, Paul Moore wrote:
> > To the best of our knowledge, everyone who enables audit at compile
> > time also enables syscall auditing; this patch simplifies the Kconfig
> > menus by removing the option to disable syscall auditing when audit
> > is selected and the target arch supports it.
> >
> > Signed-off-by: Paul Moore <pmoore@...hat.com>
>
> this patch is responsible for massive performance degradation for those
> who used only CONFIG_SECURITY_APPARMOR.
>
> And the numbers are, take the following test for instance:
>
> dd if=/dev/zero of=/dev/null count=2M
>
> ARM64: 500MB/s -> 350MB/s
> ARM: 400MB/s -> 300MB/s
Hi there.
Out of curiosity, what kernel/distribution are you running, or is this
a custom kernel compile? Can you also share the output of 'auditctl
-l' from your system? The general approach taken by everyone to
turn-off the per-syscall audit overhead is to add the "-a never,task"
rule to their audit configuration:
# auditctl -a never,task
If you are using Fedora/CentOS/RHEL, or a similarly configured system,
you can find this configuration in the /etc/audit/audit.rules file (be
warned, that file is automatically generated based on
/etc/audit/rules.d).
--
paul moore
www.paul-moore.com
Powered by blists - more mailing lists