Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp4971450img; Tue, 26 Mar 2019 22:34:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqyYlm+Kit2sS3TesnGzeYJRTlClCtFkuQ1yhZSPGFIxUSb91A2x9U1bELT8nwnaJLbxFypw X-Received: by 2002:a17:902:4101:: with SMTP id e1mr35945911pld.25.1553664882489; Tue, 26 Mar 2019 22:34:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553664882; cv=none; d=google.com; s=arc-20160816; b=GZZZIsTcwd1JoAbTAubUrSIVRORSpON6tQ3EB6TYvzfy1Cak8f3NHCbfiTCUS2zTR8 hKoCtdBN2hVHfwbpcsa5eB8NqF72FhF4vH9eDq1yblquRZnsb2M7GwuBhQ8NNFXQa0h9 wsCtU/nZaOosTDZfNC7D22hO2N3apV9TBWw5H6Ogj2adNXp2GlkhKdRkcSKxHjARvu59 Q+IAB74c7UCJUxwnD6ThOv2s/RFIkrubBEj96L9CpEaIDD/3x3MAOjU0nLW6WPrip65Q 1rix3owAqu3qspQ4py9AoNttO7dSm8jT1wfsiwY3WVQhzsFVLN1QhtYgU+Iu/9v8Qt+t aE5w== 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=vQhBPT5b9N+Na9cKRdoiaxzhFeh+nIdvYNZz+nggGfI=; b=HkNIAgcUWJ9Gu7TKWc7JbT6v17YANDvuk9/tZh9lWIzmCLCwfFS2Ev8WPDbQQocsqi W6JLR9TcJv6sDnhrAntrLhs1200UEzv7migzdJVkf+JCqx5WcT7uZH5yjBcefLUj1XEc KWAvJ8QGCenErrhT2aU0uvc8HAyJuUzQqPxUt/7RInJSWhtGaXu1EnvqAoB91OHaIMKq 47qx4CcWy2/JJ+eHHK1gLtpKMJRwdOi4au5o3E3G+ef+nFmi19EyzYQDFFV5/V7YhFk3 56Vdd6cWT1IwCF5EQK19o/de2gA2y/ollr5ChNbOwdStQ3WKcJ2s5qzj+3eS/jsoyVf/ asGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="LZYhc/ce"; 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 a22si14508047plm.263.2019.03.26.22.34.27; Tue, 26 Mar 2019 22:34:42 -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="LZYhc/ce"; 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 S1732972AbfC0Fds (ORCPT + 99 others); Wed, 27 Mar 2019 01:33:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:49506 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725787AbfC0Fdr (ORCPT ); Wed, 27 Mar 2019 01:33:47 -0400 Received: from localhost (unknown [218.148.84.253]) (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 B2DEC206DF; Wed, 27 Mar 2019 05:33:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553664826; bh=hA9dsY4to0sqzSBA2TeuG0sLGRkc7aTwCqIlM+otlVk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LZYhc/cecXucqv1HhsBTNZpEzAlz/iDrz0l46W+8b1JXG2Oyq7Ag6hAxuiTRouNJo UrfY/CQPTsiptlAx3HHvZXWaYa5+zING6/TPhqCI+VFGW6JXiCuLMrqGx6M4tfXGKt QZCldccKm7DQjDkhUdlqg7/XjRqVH3ykHupyizp0= Date: Wed, 27 Mar 2019 14:33:42 +0900 From: Greg KH To: Andy Lutomirski Cc: Andy Lutomirski , 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: <20190327053342.GA17484@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16124107-70D3-4CA0-9766-36FC6DC10128@amacapital.net> 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 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 :) thanks, greg k-h