[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhT1T4wTonW_L8CH2j1aMqSaBcUf-zH==233+ZZvSKhkwg@mail.gmail.com>
Date: Mon, 28 Jan 2019 09:52:34 -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 9:36 AM Sverdlin, Alexander (Nokia - DE/Ulm)
<alexander.sverdlin@...ia.com> wrote:
> Hello Paul,
>
> On 28/01/2019 15:19, Paul Moore wrote:
> >>> 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
>
> This test was carried out with Linux 4.9. Custom built.
I suspected that was the case, thanks.
> > -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,
>
> This is an embedded distribution. We are not using auditctl or any other
> audit-related user-space packages.
>
> > 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).
>
> I suppose in this case rule list must be empty. Is there a way to check
> this without extra user-space packages?
Yes, unless you are loading rules through some other method I would
expect that your audit rule list is empty.
I'm not aware of any other tools besides auditctl to load audit rules
into the kernel, although I haven't ever had a need for another tool
so I haven't looked very hard. If you didn't want to bring auditctl
into your distribution, I expect it would be a rather trivial task to
create a small tool to load a single "-a never,task" into the kernel.
--
paul moore
www.paul-moore.com
Powered by blists - more mailing lists