Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp958519ybb; Sat, 28 Mar 2020 14:32:28 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtlWdhLhNMBgjn+KgoqRM5UJ1FqNQaUrR5vJw3zZav66aopy6ouHbF1kl5jLUYLySk6gEI+ X-Received: by 2002:a4a:a126:: with SMTP id i38mr4637580ool.11.1585431147791; Sat, 28 Mar 2020 14:32:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585431147; cv=none; d=google.com; s=arc-20160816; b=A31rS+sg8EJXceIeckR073r0Cu6r2KjvJJWh7pdjSq+lEtScxrKdxiKOBvfM11dBlp Ngg6Z3/qlij2xsy+2CQRVwMbBsXdc4htHsENWMfIOvdL5mRrZ7NRHhLD7Fs6i1027PV1 vybbCIgzfQ3HmgWhmAbLBlGFrv7uj3Y/npkaG3Ze0VCBLjvk3FHXALI7O+3gkYE89yHV c7IHXA5LgUoSu5Tsjsq5qq6fLTRJoPMfFL1+fOSzad4pupvyMrRLP7nebMZzR+1vSsf1 H0mfo3/1lWeU/JO+D3QhhmwpAlihDLTgvoAWKISkIn4OKWQCM/e6pSnxygO2TZALpv1Q SZEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ATyiSaCgGgdR1ipPSz+SP+SzQkeYzX+7MSFro+Hlfog=; b=C4b8rE+oW6ORTx0PRGpKN46d/leneiuSlM+PgqfdVLnaf+KgGJeCL3sNAdRE9p482/ WBwDFS8rmGKlFNWvHSCHewFnABXZ8W5WglWelgcWxDEIW4k4CGGL8J+iYiYrrZ7oG/hk hn1zigyQd4WptXnZUtO+LnTHAGSGS3aYynQyv75vulp/LUs5oVMdIlXFwwgoqiK2VGO/ XcN4Mvtw2NY3ppKjCvB6pa73w+HY6AjfT/1YPh05kIE7K7L273hlXnS1LVpt7Ma/Aame 8kuuSyBXqD+rhSMe8l2Q1mWKMEonjXTHQc4ZGRf+e6hHTfjLaehUnZsnvB4TxKq3G1tm 7FSw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l15si4099735oth.29.2020.03.28.14.32.14; Sat, 28 Mar 2020 14:32:27 -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; 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=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727647AbgC1VXr (ORCPT + 99 others); Sat, 28 Mar 2020 17:23:47 -0400 Received: from raptor.unsafe.ru ([5.9.43.93]:56566 "EHLO raptor.unsafe.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727070AbgC1VXq (ORCPT ); Sat, 28 Mar 2020 17:23:46 -0400 Received: from comp-core-i7-2640m-0182e6 (ip-89-102-33-211.net.upcbroadband.cz [89.102.33.211]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by raptor.unsafe.ru (Postfix) with ESMTPSA id A2501209BD; Sat, 28 Mar 2020 21:23:41 +0000 (UTC) Date: Sat, 28 Mar 2020 22:23:36 +0100 From: Alexey Gladkov To: Kees Cook 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 , Linus Torvalds , Oleg Nesterov Subject: Re: [PATCH v10 4/9] proc: instantiate only pids that we can ptrace on 'hidepid=4' mount option Message-ID: <20200328212336.zyj5naxz4jc64tgp@comp-core-i7-2640m-0182e6> References: <20200327172331.418878-1-gladkov.alexey@gmail.com> <20200327172331.418878-5-gladkov.alexey@gmail.com> <202003281336.8354DB74@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202003281336.8354DB74@keescook> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (raptor.unsafe.ru [5.9.43.93]); Sat, 28 Mar 2020 21:23:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 28, 2020 at 01:40:03PM -0700, Kees Cook wrote: > On Fri, Mar 27, 2020 at 06:23:26PM +0100, Alexey Gladkov wrote: > > If "hidepid=4" mount option is set then do not instantiate pids that > > we can not ptrace. "hidepid=4" means that procfs should only contain > > pids that the caller can ptrace. > > > > Cc: Kees Cook > > Cc: Andy Lutomirski > > Signed-off-by: Djalal Harouni > > Reviewed-by: Alexey Dobriyan > > Signed-off-by: Alexey Gladkov > > --- > > fs/proc/base.c | 15 +++++++++++++++ > > fs/proc/root.c | 13 ++++++++++--- > > include/linux/proc_fs.h | 1 + > > 3 files changed, 26 insertions(+), 3 deletions(-) > > > > diff --git a/fs/proc/base.c b/fs/proc/base.c > > index 43a28907baf9..1ebe9eba48ea 100644 > > --- a/fs/proc/base.c > > +++ b/fs/proc/base.c > > @@ -701,6 +701,14 @@ static bool has_pid_permissions(struct proc_fs_info *fs_info, > > struct task_struct *task, > > int hide_pid_min) > > { > > + /* > > + * If 'hidpid' mount option is set force a ptrace check, > > + * we indicate that we are using a filesystem syscall > > + * by passing PTRACE_MODE_READ_FSCREDS > > + */ > > + if (fs_info->hide_pid == HIDEPID_NOT_PTRACEABLE) > > + return ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS); > > + > > if (fs_info->hide_pid < hide_pid_min) > > return true; > > if (in_group_p(fs_info->pid_gid)) > > @@ -3319,7 +3327,14 @@ struct dentry *proc_pid_lookup(struct dentry *dentry, unsigned int flags) > > if (!task) > > goto out; > > > > + /* Limit procfs to only ptraceable tasks */ > > + if (fs_info->hide_pid == HIDEPID_NOT_PTRACEABLE) { > > + if (!has_pid_permissions(fs_info, task, HIDEPID_NO_ACCESS)) > > + goto out_put_task; > > + } > > + > > result = proc_pid_instantiate(dentry, task, NULL); > > +out_put_task: > > put_task_struct(task); > > out: > > return result; > > diff --git a/fs/proc/root.c b/fs/proc/root.c > > index 616e8976185c..62eae22403d2 100644 > > --- a/fs/proc/root.c > > +++ b/fs/proc/root.c > > @@ -47,6 +47,14 @@ static const struct fs_parameter_spec proc_fs_parameters[] = { > > {} > > }; > > > > +static inline int valid_hidepid(unsigned int value) > > +{ > > + return (value == HIDEPID_OFF || > > + value == HIDEPID_NO_ACCESS || > > + value == HIDEPID_INVISIBLE || > > + value == HIDEPID_NOT_PTRACEABLE); > > This likely easier to do with a ...MAX value? i.e. > > return (value < HIDEPID_OFF || value >= HIDEPID_MAX); > > > +} > > + > > static int proc_parse_param(struct fs_context *fc, struct fs_parameter *param) > > { > > struct proc_fs_context *ctx = fc->fs_private; > > @@ -63,10 +71,9 @@ static int proc_parse_param(struct fs_context *fc, struct fs_parameter *param) > > break; > > > > case Opt_hidepid: > > + if (!valid_hidepid(result.uint_32)) > > + return invalf(fc, "proc: unknown value of hidepid.\n"); > > ctx->hidepid = result.uint_32; > > - if (ctx->hidepid < HIDEPID_OFF || > > - ctx->hidepid > HIDEPID_INVISIBLE) > > - return invalfc(fc, "hidepid value must be between 0 and 2.\n"); > > break; > > > > default: > > diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h > > index 7d852dbca253..21d19353fdc7 100644 > > --- a/include/linux/proc_fs.h > > +++ b/include/linux/proc_fs.h > > @@ -32,6 +32,7 @@ enum { > > HIDEPID_OFF = 0, > > HIDEPID_NO_ACCESS = 1, > > HIDEPID_INVISIBLE = 2, > > + HIDEPID_NOT_PTRACEABLE = 4, /* Limit pids to only ptraceable pids */ > > This isn't a bit field -- shouldn't this be "3"? > > ... > HIDEPID_NOT_PTRACEABLE = 3, > HIDEPID_MAX > > etc? I decided to choose 4 so that if later we need to be able to make a mask. I am not sure that this parameter will not have values that cannot be used together. Since now these parameters are becoming part of the public api, I decided to add flexibility. -- Rgrds, legion