Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4009304ybv; Mon, 10 Feb 2020 10:31:09 -0800 (PST) X-Google-Smtp-Source: APXvYqzuuZKo5dH1PauSV8nUbcXcrl4+FwKZSeod9Wzp9pU3JMY8oGnioiiI/Xd7apgVn+Ck0eDx X-Received: by 2002:aca:f305:: with SMTP id r5mr265453oih.174.1581359469276; Mon, 10 Feb 2020 10:31:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581359469; cv=none; d=google.com; s=arc-20160816; b=T0x35FjWpwc9UrD7O8pComE5hF3wWoXVH35a/Yf5e8ffWSk09spR4epHpHIExmOfYS mlWzat3PQXnAvWIKprS2pjq1jLdwMLMBKkcLWohaeip4+brryzFwuE9Drl9SwrqqRSJ4 2jGnTHaTQFi4/rqD41E2KIVE5XG3wk/xFh2Kqf2HzZ8wQCqKUVi8LcqJQfnLhB0RL+PX c0wRqd8wDbPEbZrn+xSXWGqWgZu+4tyl4LKZFX1O8eagpEm39K/OVreOij0PMkYVPkBx ZQr8IGxeOqFJVX4kbPXTfguYq2+dVFTZmbvs0X7v9CrOGW3XK9hzV9UH3+C2Hg5J2wv9 EBNw== 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=W7oE2peM8HMQDPxoVNJjxCxbaabHZfsB1wYtHELRAFA=; b=oGAh+wxESy1YyvnlsWE3gJSu06EaH+FfpQy4djPTqcjdThypaIW0259I3qGXZlRQna MbpGMcWm5jFN3QciCwdSnCNYmhln4WPPmAe5GCiYJebYgoGS09yBs0UVDZkI0eB6kzbw EQaME5SAfmfoEdf6U5wgcVrvPMY3iSeVPF468rosZTiatFGyPS50dXSEvK8ftK8HXKMi ABv5b5yFXbU/ERYX6BIvsZQYCc8n5OajWIWgIhLVoTq52bcBcXi2MltWLieU/6ULiBFJ aYCo0lHUfAY7Kh56/FLjow1Eg09zI2k+lxAGYewA/gqJRPgUvdgSaqVFaiSVoRWvaXNm RlzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=EF8eHmVa; 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 l131si440138oig.120.2020.02.10.10.30.57; Mon, 10 Feb 2020 10:31:09 -0800 (PST) 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=EF8eHmVa; 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 S1727522AbgBJS3j (ORCPT + 99 others); Mon, 10 Feb 2020 13:29:39 -0500 Received: from mail.kernel.org ([198.145.29.99]:49452 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727433AbgBJS3i (ORCPT ); Mon, 10 Feb 2020 13:29:38 -0500 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 144C22465D for ; Mon, 10 Feb 2020 18:29:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581359377; bh=75Y6o+R2RT1l2imBwb+jNktBnqH/sCmtNtwqXoR4Pes=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EF8eHmVaJ5TifBzp1HvD/JNbwlvbm/aA4/9GdfxXGs3EBE23gGR5jRMoWysBmEhEv bM6+LM746QhXKsuJTk3aLNyym1Qk1hyrZeoazQHonF+iT4ek20ZURTP7yQAWWJKVQT HDcYXHCPea9x7ocZPOeejOQ7WIoXpvg6lSfHI8Z8= Received: by mail-wr1-f47.google.com with SMTP id c9so9062581wrw.8 for ; Mon, 10 Feb 2020 10:29:36 -0800 (PST) X-Gm-Message-State: APjAAAVfiYZydykVkjDKy/kJ/iRdO2XUG3Z7QBXZQR4pRxmGj+oHGxIx TAORzY+fIbgzSyJBCGcGGA+K9NmRdn8+rpwDrG2jiw== X-Received: by 2002:a5d:4cc9:: with SMTP id c9mr3278410wrt.70.1581359375255; Mon, 10 Feb 2020 10:29:35 -0800 (PST) MIME-Version: 1.0 References: <20200210150519.538333-1-gladkov.alexey@gmail.com> <20200210150519.538333-11-gladkov.alexey@gmail.com> In-Reply-To: <20200210150519.538333-11-gladkov.alexey@gmail.com> From: Andy Lutomirski Date: Mon, 10 Feb 2020 10:29:23 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 10/11] docs: proc: add documentation for "hidepid=4" and "subset=pidfs" options and new mount behavior To: Alexey Gladkov Cc: LKML , Kernel Hardening , Linux API , Linux FS Devel , Linux Security Module , Akinobu Mita , Alexander Viro , Alexey Dobriyan , Andrew Morton , Andy Lutomirski , Daniel Micay , Djalal Harouni , "Dmitry V . Levin" , "Eric W . Biederman" , Greg Kroah-Hartman , Ingo Molnar , "J . Bruce Fields" , Jeff Layton , Jonathan Corbet , Kees Cook , Linus Torvalds , Oleg Nesterov , Solar Designer 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 Mon, Feb 10, 2020 at 7:06 AM Alexey Gladkov wrote: > > Signed-off-by: Alexey Gladkov > --- > Documentation/filesystems/proc.txt | 53 ++++++++++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > > diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt > index 99ca040e3f90..4741fd092f36 100644 > --- a/Documentation/filesystems/proc.txt > +++ b/Documentation/filesystems/proc.txt > @@ -50,6 +50,8 @@ Table of Contents > 4 Configuring procfs > 4.1 Mount options > > + 5 Filesystem behavior > + > ------------------------------------------------------------------------------ > Preface > ------------------------------------------------------------------------------ > @@ -2021,6 +2023,7 @@ The following mount options are supported: > > hidepid= Set /proc// access mode. > gid= Set the group authorized to learn processes information. > + subset= Show only the specified subset of procfs. > > hidepid=0 means classic mode - everybody may access all /proc// directories > (default). > @@ -2042,6 +2045,56 @@ information about running processes, whether some daemon runs with elevated > privileges, whether other user runs some sensitive program, whether other users > run any program at all, etc. > > +hidepid=4 means that procfs should only contain /proc// directories > +that the caller can ptrace. I have a couple of minor nits here. First, perhaps we could stop using magic numbers and use words. hidepid=ptraceable is actually comprehensible, whereas hidepid=4 requires looking up what '4' means. Second, there is PTRACE_MODE_ATTACH and PTRACE_MODE_READ. Which is it? > + > gid= defines a group authorized to learn processes information otherwise > prohibited by hidepid=. If you use some daemon like identd which needs to learn > information about processes information, just add identd to this group. How is this better than just creating an entirely separate mount a different hidepid and a different gid owning it? In any event, usually gid= means that this gid is the group owner of inodes. Let's call it something different. gid_override_hidepid might be credible. But it's also really weird -- do different groups really see different contents when they read a directory?