Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp599741ybh; Wed, 11 Mar 2020 07:12:36 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvZAy9jW4iPYpoZ7lM26yXi0csPJ8zqXJzCzbe1xiKcVxaId6ntGmwR4uO8PTjzhyBGn1Uj X-Received: by 2002:aca:ac46:: with SMTP id v67mr2128380oie.62.1583935956716; Wed, 11 Mar 2020 07:12:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583935956; cv=none; d=google.com; s=arc-20160816; b=C/lMZ0fkqdUcYDCGqocyPx6rIdCOrrJFYkzt0bvZT+KVLemfE7A12PU2kknx7qigV2 1ovd7YFDRltGqte2Z948CehudTW+m1ZXqJ/aFUHeqM6zmjm9ssKrmnufbwEc3HNukIPd s9Fae74KvO+zm0lFcsawqWwmb6hncTp7+Lo6G3Cma77m5iy5lB22qCkMvhLPDobZeHuY 7xHGi5hnJpqoSf5/8wNDvVZY1eOrSiQwY82wWBrJmxhAHVQbXUCOqFCzArmWoqOJFqxS tohvpf4Vw4JezknrE5pOyHlEnkXpmNCFJL6ZsWEs3Qsbq2Hefdd8NqgQe6oG+rDsFUkF 4IMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=eRXF3Lu8yM4CveHeF4EG7x/3yDcBSv2L0lKh/LedVzQ=; b=cvGWqAuHpB1wAAqeFoYuq5oIuP63dZ7TRRXFScoaa3N75mTQjFsbA+q6DVPs23lSJ4 m+O2h1lO0Uodzq9hEmx5J64D5xgT55hfjpFDonHEJTPJsFG1E5Kmb4EWcwrTon0GWxrb xN/zhkjOuyeT1yo6zhlIr3EA2dA7vdsEDiqaNFeDXstPBM/yTwc1ngCSV4UG7LGROpM1 TS2fB90Yaheatj3FsgEza+jrZeAWnptpSFuwxN+y0EN25tCaertkRHjf0Eu0G0p4h67N f/OAUQCNYklWdqOhYOKVzMuJuMsQgtxwP8YJNmlAwyD2KdUg9uUUaEQi8yreLnoLQmrf 7Uzg== ARC-Authentication-Results: i=1; mx.google.com; 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 l25si1203855otq.76.2020.03.11.07.12.15; Wed, 11 Mar 2020 07:12:36 -0700 (PDT) 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; 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 S1729702AbgCKOLT convert rfc822-to-8bit (ORCPT + 99 others); Wed, 11 Mar 2020 10:11:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:53812 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729646AbgCKOLT (ORCPT ); Wed, 11 Mar 2020 10:11:19 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 77F5B20726; Wed, 11 Mar 2020 14:11:17 +0000 (UTC) Date: Wed, 11 Mar 2020 10:11:15 -0400 From: Steven Rostedt To: Dmitry Vyukov Cc: Jiri Slaby , Greg Kroah-Hartman , Tetsuo Handa , Andrew Morton , Matthew Garrett , Andi Kleen , "Theodore Y . Ts'o" , Alexander Viro , Petr Mladek , Sergey Senozhatsky , Arnd Bergmann , Linus Torvalds , LKML Subject: Re: [PATCH v2] Add kernel config option for fuzz testing. Message-ID: <20200311101115.53139149@gandalf.local.home> In-Reply-To: References: <20200307135822.3894-1-penguin-kernel@I-love.SAKURA.ne.jp> <6f2e27de-c820-7de3-447d-cd9f7c650add@suse.com> <20200308065258.GE3983392@kroah.com> <3e9f47f7-a6c1-7cec-a84f-e621ae5426be@suse.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 Mar 2020 07:30:01 +0100 Dmitry Vyukov wrote: > Steve, I am not sure if by lockdown you mean the existing lockdown > mechanism, or just something similar in nature. As Tetsuo pointed, the > possibility of using the existing lockdown mechanism for this was > discussed here (and rejected): > https://lore.kernel.org/lkml/CACdnJutc7OQeoor6WLTh8as10da_CN=crs79v3Fp0mJTaO=+yw@mail.gmail.com/ From Matthew's message a couple of emails earlier: > Simplicity. Based on discussion, we didn't want the lockdown LSM to > enable arbitrary combinations of lockdown primitives, both because > that would make it extremely difficult for userland developers and > because it would make it extremely easy for local admins to > accidentally configure policies that didn't achieve the desired > outcome. There's no inherent problem in adding new options, but really > right now they should fall into cases where they're protecting either > the integrity of the kernel or preventing leakage of confidential > information from the kernel. Now, if you are worried that fuzzing will cause harm, or crash the kernel, it sounds to me, whatever fuzzing did would satisfy Matthew's "integrity of the kernel" portion. In other words, I believe fuzzing folks should be working with the lockdown folks and letting the lockdown folks how root can crash the system. I would think from a security point of view, that if there's a known method to take down the kernel, and I don't want root to be able to do so, we should either fix the kernel to not be able to do so, or if that interface is "you should know what you are doing" then it should be something an admin could lock down to keep other admins who don't know what they are doing from crashing the system. Or teach the fuzz tool not to do specific bad things. Honestly, if you just go with a single config to prevent interfaces from crashing the system while running a fuzz test, then you just lowered the usefulness of the fuzz test, as it will never find legitimate cases where that interface crashed the kernel when it should not have. We are currently trying to clean up the tracing / probing code to not be able to crash the kernel with any interface. It's hard, but it is a goal. -- Steve