Received: by 10.192.165.156 with SMTP id m28csp1126892imm; Wed, 11 Apr 2018 12:57:59 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/6LQkVSaf/LtHn+M+mZxPj8+oPY4/z4gazoUMlKpAd+B1q/B8ihTBKftw5k4108K0dC94W X-Received: by 10.99.66.69 with SMTP id p66mr63345pga.290.1523476679395; Wed, 11 Apr 2018 12:57:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523476679; cv=none; d=google.com; s=arc-20160816; b=BTbqfS+OEpNqy2yU7DOVbzrV/SAhT1lbk+yHtyI682Jn7RFgEZWr/+q0G3nimq/OE+ S0j0gIANxuMHbVfoGzrBuJofdHwc3YV284BNEwfanxb+rJNGcVwvvWhBeR27p3ciBWwO GAG6iJPpnpS0AbzsjZGAFfiJtD5FP1Cg8Hkqj/qBLs/TdnaeK5mCc3SouNbzv/HIMxjx auwl79zgUw6dcVgCDIPPBQGXCslO3SlGWpLLHluiBSRK7BEIWdCFHXnKQUWNKE0nr33a lv7S+Kh4eqP1NXWdyqYXJxlM0bEc+q0oSUyhT9xOKMzhUjbJseFZ9XZeL7lfDi06XdqC SbmA== 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:arc-authentication-results; bh=l1x2x8TBqwUbALtbRjTAQF1zp6LygBxhhmjKv6xXUOg=; b=eGsSj8dm7tRvlePdgB6co0adkZm3273z7io9OgGqOauJqL03Yt/zaeaxa3pG1Cki1J hp6zN71ngqeCkxursaGnTvYAIoOa+kFIodRW+GhxT03zGHgy18bgDM0CHOxyYfut2dKJ LL4cxd6CKormTTa15qE8gdmLGE5n++9lmjpJfTgocOmeJPIdqnJcvv76Bu6OeGu95msD 2UXJLni1mGiKKAeuSgP/TzivwGw0QH8znYwOceKKbWntMIqi302FNXB3gyLIGsCxZDEk HanJyWx1wN95FmkBtzvadw4jdJnqWehXTqqGkUizLK2VsMcyTBka8f3oKnzuq68z9mb6 Im/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=EV3dUIcJ; 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 m15si1174535pgs.170.2018.04.11.12.57.22; Wed, 11 Apr 2018 12:57:59 -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=@messagingengine.com header.s=fm2 header.b=EV3dUIcJ; 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 S933286AbeDKTyr (ORCPT + 99 others); Wed, 11 Apr 2018 15:54:47 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:36819 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756700AbeDKTyo (ORCPT ); Wed, 11 Apr 2018 15:54:44 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 30E3920E18; Wed, 11 Apr 2018 15:54:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 11 Apr 2018 15:54:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=l1x2x8TBqwUbALtbRjTAQF1zp6Lyg BxhhmjKv6xXUOg=; b=EV3dUIcJTH/YbkFOSh8th5CrAMS9rjwnjzbbf7fpLrooh EaTqX59ZBM2sSSPnVSA/7Otmt6IKhj9q8UCsh303FwCeDBsAcW4E9+dkdrn20bKh /UYxuc4CO5Z/kUkbVvAbrqwoKhiC+mEID8oM56XVDA0477ZZsrFVQiCMtxhS/yUw VD2DVgwpW8W1bPKG+JSCmwUC1QVfBeFT2Wl54G2Pc+UWCOADRMm9i+4KkDJDHr0P 1F+2YMY5S1RGgfVCvReMo7YgIAsn5FbKWtDFM13z1T0vmRpmuaudxSgNsgKFO/lX 4+LdsDzuLEI087k0lFTHcpFiEArX5frJb1PAyF4tQ== X-ME-Sender: Received: from localhost (lfbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.messagingengine.com (Postfix) with ESMTPA id BF951E509A; Wed, 11 Apr 2018 15:54:42 -0400 (EDT) Date: Wed, 11 Apr 2018 21:54:36 +0200 From: Greg KH To: David Howells Cc: torvalds@linux-foundation.org, linux-man@vger.kernel.org, linux-api@vger.kernel.org, jmorris@namei.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down Message-ID: <20180411195436.GA7126@kroah.com> References: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk> <152346403637.4030.15247096217928429102.stgit@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152346403637.4030.15247096217928429102.stgit@warthog.procyon.org.uk> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 11, 2018 at 05:27:16PM +0100, David Howells wrote: > Disallow opening of debugfs files that might be used to muck around when > the kernel is locked down as various drivers give raw access to hardware > through debugfs. Given the effort of auditing all 2000 or so files and > manually fixing each one as necessary, I've chosen to apply a heuristic > instead. The following changes are made: > > (1) chmod and chown are disallowed on debugfs objects (though the root dir > can be modified by mount and remount, but I'm not worried about that). > > (2) When the kernel is locked down, only files with the following criteria > are permitted to be opened: > > - The file must have mode 00444 > - The file must not have ioctl methods > - The file must not have mmap > > (3) When the kernel is locked down, files may only be opened for reading. > > Normal device interaction should be done through configfs, sysfs or a > miscdev, not debugfs. > > Note that this makes it unnecessary to specifically lock down show_dsts(), > show_devs() and show_call() in the asus-wmi driver. > > I would actually prefer to lock down all files by default and have the > the files unlocked by the creator. This is tricky to manage correctly, > though, as there are 19 creation functions and ~1600 call sites (some of > them in loops scanning tables). Why not just disable debugfs entirely? This half-hearted way to sorta lock it down is odd, it is meant to not be there at all, nothing in your normal system should ever depend on it. So again just don't allow it to be mounted at all, much simpler and more obvious as to what is going on. thanks, greg k-h