Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp5606730img; Wed, 27 Mar 2019 11:34:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwvyCWFRYVgVXJ3+s1Dz8K8+92/7Xu/fcGQJQa+fkRANXHQVLNPOSpftkV3nFkWSLh8XDfU X-Received: by 2002:aa7:8019:: with SMTP id j25mr37214333pfi.77.1553711684138; Wed, 27 Mar 2019 11:34:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553711684; cv=none; d=google.com; s=arc-20160816; b=LCPYp5uy5T/3xaJXow5013+66jc9Au5XRUsbuuUdYKq89/9buIx1/uiZ6ca0VrOMRt sqUHAZtTL0pouJRRuOz4hMsEOkhl3G/BqzFfsbQYFgUiE2sWWSACrpc4r19SJ+Kegl6G j2LmzC0fEWl4UO2Yhdzf8dNKIl45EBQn5SaL2Ot8DHcjQDdVwnTde2llye7DuwEsxr1U cG+fsGumZE1j5KaSFbC93O92QVyB6OcPNGnYgw3HmzwXcshAj2a/cRqCP2uG71CZ2kcs M9Jzj/gYuKkMY2phG3vGXASJWiUhPMMDVb+s/DBxebQhWcqP/fdLmhI/i77mXAuyRyey EAtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ncHIn7Qfqp4p27GQGGRlOh0Sq8lL8v+pLGQEqKQ/2EQ=; b=Yfe1Sp6kI58LJaRLJkFuWUQHfs4fmDBCzm3mczEXi3yHrhUtP/2Lg7ZZUJ3taaBTFf KtxfOoEAgmmwCBXknYobHlHXwdikAOUp81CYJ8nLplrO+OlSC7s6kHb+E5HFPktuLuGz KKdH7vQ0o9TINCRPyjq8ji+LLwEyJCHegIGAOEAKuZ7v/rb/8Y/D7O8ZttWurTntqTMy sJkOvh9OtD67hxJVONKa2Nq6x3fGmhasKm1uZhXYGPqL8qPlQVtdpPo5ndIcBTDAWAS+ nqbw7tIF/QNWoISHPtl2m+h+MVoIzj0+TMiuasQELC/55XrRlML+a6TDf/n17lhxhBZi /a1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=2cki3BQ3; 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 l129si18902121pgl.541.2019.03.27.11.34.28; Wed, 27 Mar 2019 11:34:44 -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; dkim=pass header.i=@kernel.org header.s=default header.b=2cki3BQ3; 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 S2391831AbfC0ScC (ORCPT + 99 others); Wed, 27 Mar 2019 14:32:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:52802 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728643AbfC0ScA (ORCPT ); Wed, 27 Mar 2019 14:32:00 -0400 Received: from localhost (unknown [88.128.80.233]) (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 54944204FD; Wed, 27 Mar 2019 18:31:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553711519; bh=JkniCfTXMqYRp0YFhUkfp8QCK4JuIgZmgdfsNhO0zN4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=2cki3BQ3qlGqon5UBAwAsFt/nI3qAv6CUDDtvg5CWd3adDjQB1GeEgYp1z+MKfnsM VHvEFprWizcDCh1O5f+4d4AEAga/BsBiI7/Bl2tJeCOQtkCdV44stIkoFBpCsq+NA9 s1hLSeJScln20jv+1G9vkO6eIFeO2pDFDKymWTG4= Date: Thu, 28 Mar 2019 03:31:52 +0900 From: Greg KH To: Andy Lutomirski Cc: Matthew Garrett , James Morris , LSM List , LKML , David Howells , Linux API , Matthew Garrett Subject: Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down Message-ID: <20190327183152.GB9371@kroah.com> References: <20190326182742.16950-1-matthewgarrett@google.com> <20190326182742.16950-26-matthewgarrett@google.com> <20190327003057.GA27311@kroah.com> <20190327050615.GA548@kroah.com> <16124107-70D3-4CA0-9766-36FC6DC10128@amacapital.net> <20190327053342.GA17484@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 27, 2019 at 10:39:53AM -0700, Andy Lutomirski wrote: > On Tue, Mar 26, 2019 at 10:33 PM Greg KH wrote: > > > > On Tue, Mar 26, 2019 at 10:29:41PM -0700, Andy Lutomirski wrote: > > > > > > > > > > On Mar 26, 2019, at 10:06 PM, Greg KH wrote: > > > > > > > >> On Tue, Mar 26, 2019 at 09:29:14PM -0700, Andy Lutomirski wrote: > > > >>> On Tue, Mar 26, 2019 at 5:31 PM Greg KH wrote: > > > >>> > > > >>>> On Tue, Mar 26, 2019 at 12:20:24PM -0700, Andy Lutomirski wrote: > > > >>>> On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett > > > >>>> wrote: > > > >>>>> > > > >>>>> From: Matthew Garrett > > > >>>>> > > > >>>>> debugfs has not been meaningfully audited in terms of ensuring that > > > >>>>> userland cannot trample over the kernel. At Greg's request, disable > > > >>>>> access to it entirely when the kernel is locked down. This is done at > > > >>>>> open() time rather than init time as the kernel lockdown status may be > > > >>>>> made stricter at runtime. > > > >>>> > > > >>>> Ugh. Some of those files are very useful. Could this perhaps still > > > >>>> allow O_RDONLY if we're in INTEGRITY mode? > > > >>> > > > >>> Useful for what? Debugging, sure, but for "normal operation", no kernel > > > >>> functionality should ever require debugfs. If it does, that's a bug and > > > >>> should be fixed. > > > >>> > > > >> > > > >> I semi-regularly read files in debugfs to diagnose things, and I think > > > >> it would be good for this to work on distro kernels. > > > > > > > > Doing that for debugging is wonderful. People who want this type of > > > > "lock down" are trading potential security for diagnositic ability. > > > > > > > > > > I think you may be missing the point of splitting lockdown to separate integrity and confidentiality. Can you actually think of a case where *reading* a debugfs file can take over a kernel? > > > > Reading a debugfs file can expose loads of things that can help take > > over a kernel, or at least make it easier. Pointer addresses, internal > > system state, loads of other fun things. And before 4.14 or so, it was > > pretty trivial to use it to oops the kernel as well (not an issue here > > anymore, but people are right to be nervous). > > > > Personally, I think these are all just "confidentiality" type things, > > but who really knows given the wild-west nature of debugfs (which is as > > designed). And given that I think this patch series just crazy anyway, > > I really don't care :) > > > > As far as I'm concerned, preventing root from crashing the system > should not be a design goal of lockdown at all. And I think that the > "integrity" mode should be as non-annoying as possible, so I think we > should allow reading from debugfs. Sorry, the "crash the system" is not the issue here. The issue is if everyone can "ensure" that "everything" in debugfs is "safe" for this mode of "lock down". Given that no one has any idea of what really is in debugfs, and to try to compare that with the design goals of what "lock down" really is trying to achive, I think the goal of just giving up and restricting access is fine if that makes people feel better about this whole thing. If this is locked down, it is going to cause distros more pain in debugging user's issues, but that's their choice, not mine :) thanks, greg k-h