Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20151208164237.15736.42955.stgit@localhost> <5490ae28-251b-bfda-38a6-5be201a4a8d8@nokia.com>
 <CAHC9VhQsVFY1LAakAUUCBZw6nmSy0-eoFrhQgVQrkqgAsWVGhQ@mail.gmail.com>
 <4fb6def1-a1d9-8af0-394c-f92224884d18@nokia.com> <CAHC9VhT1T4wTonW_L8CH2j1aMqSaBcUf-zH==233+ZZvSKhkwg@mail.gmail.com>
 <8bf5d613-9b27-381d-283b-c8892483f424@nokia.com> <CAHC9VhR25UdWPSRurefEX3YjM80DEh5BXETvK4na3Ym+k2=9xQ@mail.gmail.com>
 <20190128210328.64b7719c@ivy-bridge>
In-Reply-To: <20190128210328.64b7719c@ivy-bridge>
From:   Paul Moore <paul@paul-moore.com>
Date:   Mon, 28 Jan 2019 15:08:56 -0500
Message-ID: <CAHC9VhSCFiEfzcwwkDdMsyh0xa2zh-WDTbv55tsDXYU4Td0zDQ@mail.gmail.com>
Subject: Re: [PATCH] audit: always enable syscall auditing when supported and
 audit is enabled
To:     Steve Grubb <sgrubb@redhat.com>
Cc:     "Sverdlin, Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@nokia.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        "linux-audit@redhat.com" <linux-audit@redhat.com>,
        Richard Guy Briggs <rbriggs@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jan 28, 2019 at 3:03 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Mon, 28 Jan 2019 11:26:51 -0500
> Paul Moore <paul@paul-moore.com> wrote:
>
> > On Mon, Jan 28, 2019 at 10:38 AM Sverdlin, Alexander (Nokia - DE/Ulm)
> > <alexander.sverdlin@nokia.com> wrote:
> > > Hello Paul,
> > >
> > > On 28/01/2019 15:52, 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@redhat.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.
> > >
> > > I've done a quick test on my x86_64 PC and got the following
> > > results:
> >
> > ...
> >
> > > Which brings me to an idea, that the subject patch should have been
> > > accompanied by a default "never,task" rule inside the kernel,
> > > otherwise you require an extra user-space package (audit) just to
> > > bring Linux 4.5+ to 4.4 performance levels.
> >
> > [NOTE: I dropped pmoore@redhat.com from the To/CC line, I left Red Hat
> > for greener pastures several months ago.]
> >
> > Well, it generally hasn't been an issue as 1) most people that enable
> > audit also enable syscall auditing and 2) most people that enable
> > audit have some sort of audit userspace tools to work with the audit
> > logs (and configure audit if necessary).  I don't want to diminish
> > your report, but this change was made several years ago and we really
> > haven't heard of many issues surrounding the change.  If we can ever
> > get all of the different arches to support syscall auditing, I'd love
> > to get rid of the syscall auditing Kconfig knob entirely.
> >
> > If you wanted to put together a patch that added a single "-a
> > never,task" rule on boot I could get behind that, just make it default
> > to off.
>
> That will make processes unauditable for everyone. That's how it gets a
> speedup is not entering into the audit machinery.

That is pretty much what is being asked for in this thread.  It's
really no different from what Fedora/CentOS/RHEL (and who knows how
many others) ship with their default audit config.  It's important to
note that you could always delete this rule at runtime; all that is
being proposed is to have the kernel populate the the audit ruleset
with the "-a never,task" rule *IF* the proposed kernel Kconfig option
is enabled (and it would default to being off, you would have to turn
it on during build).

> I suppose its possible that people may want MAC hardwired events but no syscall
> events. I don't know if there are other kconfig audit options. but
> maybe getting it down to audit enabled and syscall auditing as the only
> choices is probably the most performant.
>
> -Steve

-- 
paul moore
www.paul-moore.com