Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp5560710img; Wed, 27 Mar 2019 10:42:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqzq1Naqut8ksh7cy0nuW7pwGAcm/IXqr8f3qlj6N/bhxsfX500EMnVAlPGFkh9ICZkhHuyJ X-Received: by 2002:a17:902:87:: with SMTP id a7mr37794718pla.295.1553708554637; Wed, 27 Mar 2019 10:42:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553708554; cv=none; d=google.com; s=arc-20160816; b=rRrfv8K5QJWbp3XV9LmUxf0R6X/7/rr5Nvzp6BZufwanUhLJe/ZTkXr5hZ2kQ6/shW zwK8Gr5rc/VFSf3P1xYgAprbCsmAxSh9Fv1wunwaqxX65Ru2SKHoKxVNQ5cyKGIYKg/m jk1LoER84tM7YYDkJSfhEUbaBnj9mKktfe1XEgeybxfKbKtpmNSESGOlL5w8ZGcnfDI9 r6VZ9PwGvTW/xoBH9vMtI5yJugp1Tisy3uSer068XSoSK6R6f14UqTFZdIVR6Q62YCgd amuifGakQAcPxZ53Ui6oeR3dB/5acvpWq1kjyiIutHjA1NtYDROF3vWI3Ppdl9pBQcL+ NOew== 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=9dfkf0nuW2iQ0MDaFbSQ4DAA9Qm48wmrqPAOFZfL3ns=; b=XOthMNZR3bPlake/lCyj4p/K99NgiWAtst4FBUiawU2neURWChvi8nd3bkIPYdj3GV o+ns82ryjuD0TZdQy89i7wYRItSs7/f7lZ+uSXQqOUNjVdpG9y7Ug2yEcCQwWdtGACKy Tz9r/Tc2caK8WtJoT4lCxhGI/Jvo2AE1rSHl+zU2uzySOYXZPYKwW8QU+srk0KMj2LPI KSVobYqtAebrzkSVulKpkCk+jaNmk9JMCaq8/cVd9dqEkSkcIrtnGzuOM8ACJpOslJhe Puu6UJRtPKgPh853jPHG2O4pXDeuht4w9yZpL4vyG3xNxhfMJ11CjE95epEuqMSn5KO5 W9sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=aCRstgT4; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v124si4463501pgb.475.2019.03.27.10.42.19; Wed, 27 Mar 2019 10:42:34 -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=aCRstgT4; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728755AbfC0RkM (ORCPT + 99 others); Wed, 27 Mar 2019 13:40:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:60790 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727937AbfC0RkH (ORCPT ); Wed, 27 Mar 2019 13:40:07 -0400 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F09492082F for ; Wed, 27 Mar 2019 17:40:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553708406; bh=jxqEa+uwiuNr1eLweO/E+2QzBcyhsLcjSwfwnHSiZww=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aCRstgT4IpUl3BZwNEnBJqzuH+iPi1XtD361b/M9ZbJ11FUvVCh5zD2T6vY3dtrk/ 37Uap6XbbreTgs85NG6RJg4Knn+Fkq92xi33UpK1YcoCl9/Wr3seOUKxGYNO5wlTIN h0MKg8RwqsxkRw5Bf4dqA9SOUZ0stEMHTwPDlpqg= Received: by mail-wr1-f44.google.com with SMTP id k11so12211339wro.5 for ; Wed, 27 Mar 2019 10:40:05 -0700 (PDT) X-Gm-Message-State: APjAAAUuFN/RdsNITr2to/TObXrvbkVc12VPaG3H+X2ZeE+YvqXYmMJc CNw7bYxzHRi/k/al9diPHg5CDH9x6WR6he8d/+J2og== X-Received: by 2002:adf:f011:: with SMTP id j17mr22216637wro.330.1553708404521; Wed, 27 Mar 2019 10:40:04 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20190327053342.GA17484@kroah.com> From: Andy Lutomirski Date: Wed, 27 Mar 2019 10:39:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down To: Greg KH Cc: Andy Lutomirski , Matthew Garrett , James Morris , LSM List , LKML , David Howells , Linux API , Matthew Garrett 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 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.