Re: [PATCH] audit: always enable syscall auditing when supported and audit is enabled

[Steve Grubb]

On Mon, 28 Jan 2019 11:26:51 -0500
Paul Moore <paul@xxxxxxxxxxxxxx> wrote:

> On Mon, Jan 28, 2019 at 10:38 AM Sverdlin, Alexander (Nokia - DE/Ulm)
> <alexander.sverdlin@xxxxxxxxx> 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@xxxxxxxxxx>  
> > >>>> 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@xxxxxxxxxx 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. 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