Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3951978imu; Mon, 28 Jan 2019 14:02:07 -0800 (PST) X-Google-Smtp-Source: ALg8bN7QJixrvV+ChtVZkHy+pKWqLz3YbT/+cyN9psxi98aI6TWD1LRbJ57+BVoWkZFQnliMDDdE X-Received: by 2002:a63:c24c:: with SMTP id l12mr21467567pgg.146.1548712927480; Mon, 28 Jan 2019 14:02:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548712927; cv=none; d=google.com; s=arc-20160816; b=s7PftFRMibUTWbKj1tztEFNcjah39ZjgyI1NPnaDmdzoz+2HpSztoKYjztJAX3KBEy C+NmqSjnlQNUothnrIxaTODhp+LFGq5ok/dWfTXUcaNyAsBLacBXA7+/eKW0zGgbB9Gc fGDxLZAp1ety2TJhmU1dVZRRPtfn4mq7ALeoqrDD3hK6qLEDwMv9trxoR7scwsSr7//U 20jBjRudA44/w559AdiOl310lGJHTxL1LBL6NzeGJn0SWU75iHZGs578XKt3UOGG5Yrz YaqiyfqdIvEnME3bLjUPSbkGpQl8jyUM+c1aIXciCqdg1dvrNkFWfLFbs36rYHUl3/5g owPA== 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=LoHgW2d3BE6j6Tu6n40ERwtLyjY1HPYWgpEU7vefcGM=; b=ZUFJmuYPNtJoit1ALLgvBXB8NUd7K0TJH6xOUnPHi0AJXYPmGSw0O8wwMKOSKGlYwQ Vj/FmUsX7uLsHXrE5X1o6z8MevB6yk9h3L49s2YoRJNakksHysZ2mYVlXtbhFF1uxuij moyI3buqMbrnr4PpQEDJ2JEv7YpCuFdxktHJrPwEAM2hZlxXe9BIWpVUNoYaYK6WBvvJ UpigNWlY+oIsPNtZVysZnMWzKQHMQGqtn7ml2M143zdxq+w10ugLg5uomrGx/GgVuCky tBPXwAaQLwKqqYlDFvPkEiF4uASjy87tjCxXKQWM3iqX0epKl/HedaCckh2y4RIeVatN UnxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=XYwiYgro; 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 c20si34591709plz.391.2019.01.28.14.01.51; Mon, 28 Jan 2019 14:02:07 -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=XYwiYgro; 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 S1726913AbfA1WBq (ORCPT + 99 others); Mon, 28 Jan 2019 17:01:46 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:44380 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726766AbfA1WBp (ORCPT ); Mon, 28 Jan 2019 17:01:45 -0500 Received: by mail-lj1-f195.google.com with SMTP id k19-v6so15653819lji.11 for ; Mon, 28 Jan 2019 14:01:43 -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=LoHgW2d3BE6j6Tu6n40ERwtLyjY1HPYWgpEU7vefcGM=; b=XYwiYgrouLKXOq762t0nxAy9pVxuAW/+JCz3QhmmM6Y9XQQHBZmwZNvpT/hsDPZqKh xAwVEICnmaOduGl0vTYlQWrozwdOfywXK3/ZaI4v7fWWHifPHgX5pq74/qy04pyJZwyC tA1PvZUTOI7fo+4KSG0A3F6N7AaJRyLhF6Sodya4IFhr4pl8bzTm4y/bJLa/ONoPABLp 20TVPAvp2/oSy3bI+ybiG9YAwLuZxudMMu0FnD2mln4cO4Bq/F0Mh/AiIihNXBlniLlm zmI+eQspN4a2hm57OvLb/KnFTo9NuzIEqw35EmIkhTs+sIKKhahpsO2uPGfD/mb27cJC vEFQ== 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=LoHgW2d3BE6j6Tu6n40ERwtLyjY1HPYWgpEU7vefcGM=; b=VOXBv0vWYOetaPMblecmZDUvN46LzxQPGJk0H5TqoXzoCdiFly4mE8+UqN9o3id7o+ 508Zxhl0QwGeuIZfK4OibJTjii/xpEcklyMc7zIBAWTc7p2tbgfwByO3rvP3BGT5FOew nukDXV1jOeZztFA0xhd+Jdtf2yzQZ4fLi3IKCooLQS4NCBPUrzoJMEuuXSOTo9fP9jKw XuDB9uQJPVTjdFJTe7REMt9bgUexyqhNl1GHLZ14QyQp7zBx+ssikvl2R3j3QB0+PI5y L8hS19g2u1/OxgWXFv6d+5W8Y+UJbrRkPIdmhgWxfCd9imlN5Gk7D9rqsmXMzPcDXChp nwwg== X-Gm-Message-State: AHQUAuawQXRzQwLbIRLpV4JX7zKcpZAhtNAKPhAoSXN9pw/mKx7CyN1L RC/jGebENpNuYQmRJABjhEwJejhBa/kFBVdkRLss X-Received: by 2002:a2e:8546:: with SMTP id u6-v6mr4242210ljj.95.1548712902143; Mon, 28 Jan 2019 14:01:42 -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> <20190128221951.57a5e03b@ivy-bridge> In-Reply-To: <20190128221951.57a5e03b@ivy-bridge> From: Paul Moore Date: Mon, 28 Jan 2019 17:01:30 -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 4:20 PM Steve Grubb wrote: > On Mon, 28 Jan 2019 15:08:56 -0500 > Paul Moore wrote: > > 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). > > Yes, but you can't add the auditable flag back to the task struct > because syscalls never enter audit machinery where it can be added back. > Meaning that even if you wanted to audit, there will be processes you > never can audit. Whereas deciding via auditd, they become unauditable > only after auditd loads the rule. Prior to that they are and all > processes are auditable if you decide to audit. So, this is > fundamentally different than what fedora does. What I'm suggesting is adding an audit rule, just like Fedora, the only difference is that it is going to be populated at boot by the kernel. Sure, it is going to happen earlier than if you use auditctl during boot, but arguably if you want to disable all the syscall auditing, this is what you want. Calling it fundamentally different from what Fedora does is not correct. For the record, this is something I would only recommend for a limited number of use cases (e.g. limited embedded environments with no need for syscall auditing), as for most users it is better to install a proper audit userspace and just configure it with auditctl during boot. -- paul moore www.paul-moore.com