Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3859952imu; Mon, 28 Jan 2019 12:10:01 -0800 (PST) X-Google-Smtp-Source: ALg8bN59WZukZe8THWrOLwJ89LPKvRrdst3RAlOx1y6lwqbPIM5HfYrBO9QH85pl5XYOoDKueZZM X-Received: by 2002:a62:2781:: with SMTP id n123mr23560372pfn.138.1548706201078; Mon, 28 Jan 2019 12:10:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548706201; cv=none; d=google.com; s=arc-20160816; b=c6KiLzQmxEYznePRNaMlZBXr5BYKYrxsZNFNQtVBElJl2nlBVANxMCPQAOSlByYMNm SuiaynJBJ0LZBYQMwH4MCWHWwCzLk5wlISOmCPZCXcXLlGrla0eTQ5Y1oUUaEwTGfFs9 aubS1p4m67tIwNDlqVZulIOmyE/PtnEPdx20U9MtbL+/YNtdCA135R8Yc12s5WD83F2z 7Reu80vwpgiKM6y/Gk+qXFdl9n8eWjV8OfuY+8mJ6PV/5arBDfEN6vkiYiU6SlsyGWZe NqODA0pN18dOVeA2V/yRXUPukbBj+tIcGb6dz3lxj6xoCawgsEz3LOi5boPj67xhaPhG 4AMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=wj09Bp4QXmjm5sIMaQFHXlso01pD8LPND+Bf5X0tqcw=; b=ToGVFugklrYpIMG4ncUDPmToF0pg3iQT7XBgfkzDxPdCNLFjdhgX6MD8N5Ma7nbZTI TNOtE5qSSdcuLQjZnZ4VPFWHClMXEKFZtyEdBAm6grZLicd5oyGiXsPEpw1Zer5jMcdk sWwSu25wzRWVYITp+a/KRoDpNpclMbPCLe/LfmPry+Zmf+IPD9I+rGp39pYxe7Aw2D7G YDaCPZ+e1Cj9t65sF9O1u1NFHZHYhZisRMlP/sY+hYeI90UQybmqJ5ryLuoLgiVfd9fe zoZOR8HTAGaZnpeWMd1cVFjWLHlKOgFUxE+5DpT0LsLRf0VDOjMBora+F+z5spGxYsQT 0evw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b="BlEScL/V"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g98si20353245plb.99.2019.01.28.12.09.45; Mon, 28 Jan 2019 12:10:01 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b="BlEScL/V"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727096AbfA1UJL (ORCPT + 99 others); Mon, 28 Jan 2019 15:09:11 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:45983 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726661AbfA1UJL (ORCPT ); Mon, 28 Jan 2019 15:09:11 -0500 Received: by mail-lf1-f67.google.com with SMTP id b20so12836248lfa.12 for ; Mon, 28 Jan 2019 12:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wj09Bp4QXmjm5sIMaQFHXlso01pD8LPND+Bf5X0tqcw=; b=BlEScL/VBFp8J4ffQd5Ql6/cOsGxr4VOeUDWeAELmblFAZiTIKH8CTidebr25oR/6h sY496mhYA76OXqGCoQ+buDHbop496dvyJtzRo5/apDjzfLAZRDgDSIgwBKMZgSuO+JG5 gDP5BnGzGWHTIm4ZPXjX+Fz/c5R/k9PK/05tK1XbAE6eHrlPQhCzFbB6X0tuCyhzrCCL ATFuYVmAjvSZ/zUiVOIqy2jlmhtU+6tTERQq1qkcaDGX/ox5brumUfMl/SOFmqT4O+PP NSwhC2+CpEbebugz9YQzb/VpHFJeHL1/hDMBokx0d9FafHJqKa0qSUoXunO2dzm4kZoT oDOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wj09Bp4QXmjm5sIMaQFHXlso01pD8LPND+Bf5X0tqcw=; b=Hn/xQK72IXRRGZkN7aBTnyVIftTvyw/jtPcr4AxF2ZGjMw8nR80ah2vv5NwB+ODOaS eyGbPvKMXd0yQU9TAHrGyGohiFp+Kg2tUyYU2RcoPCxIWF5fqXzCFIVhUOfdB1NkeXCy fT+HfvWVfCe8oDdMN+YqNFdHfDCbQOptsiMxNvVhLGXIdTW29YFdodALEUjNUXD5WyJE jxaqxEzy+/0rrzOr86Tbynzp1F3wAo1QBe43SMZH6upMBdwTM7+xVKCkvP1mv3zQoS/K de+4TzoQ4GONDkyMvKdNuvnq2u+Ch6W9xk3lWTJRLDEUEtgzNaBhrsPbe2NM9PUV4TyK +tYg== X-Gm-Message-State: AJcUukcj0DM0wl6MKrE8VugWAxTepA2AWyTFuNjofJzfAQ5EYr06CJ6X PZh2rAORNmDiuQ4BmhkmsUKF5Q1VnGaQU99PZsXl X-Received: by 2002:a19:cbcc:: with SMTP id b195mr17546271lfg.117.1548706148087; Mon, 28 Jan 2019 12:09:08 -0800 (PST) MIME-Version: 1.0 References: <20151208164237.15736.42955.stgit@localhost> <5490ae28-251b-bfda-38a6-5be201a4a8d8@nokia.com> <4fb6def1-a1d9-8af0-394c-f92224884d18@nokia.com> <8bf5d613-9b27-381d-283b-c8892483f424@nokia.com> <20190128210328.64b7719c@ivy-bridge> In-Reply-To: <20190128210328.64b7719c@ivy-bridge> From: Paul Moore Date: Mon, 28 Jan 2019 15:08:56 -0500 Message-ID: Subject: Re: [PATCH] audit: always enable syscall auditing when supported and audit is enabled To: Steve Grubb Cc: "Sverdlin, Alexander (Nokia - DE/Ulm)" , Daniel Borkmann , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Alexei Starovoitov , "linux-audit@redhat.com" , Richard Guy Briggs Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 28, 2019 at 3:03 PM Steve Grubb wrote: > On Mon, 28 Jan 2019 11:26:51 -0500 > Paul Moore wrote: > > > On Mon, Jan 28, 2019 at 10:38 AM Sverdlin, Alexander (Nokia - DE/Ulm) > > 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 > > > >>>> 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