Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1142021ybk; Thu, 14 May 2020 01:16:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwB5F38Cut59ee6QqfNpdZetpwCNzQotDs5M0y/B+IJLpkMOheCZS4OuVcwJ0yzsEYnqlWa X-Received: by 2002:a17:906:bce6:: with SMTP id op6mr2680398ejb.337.1589444168350; Thu, 14 May 2020 01:16:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589444168; cv=none; d=google.com; s=arc-20160816; b=Z1RfsPYNYkL9nr9z06MmR8b+ZvoSm9hojJ9luJacFqzatr3lLs1AS9ojiNkmKOrn17 EB3FqY4UwQ3PJbGrhSm0evLUxlgf9KXfob8n/Do394pUWQxBqeKzlJODyApDzARqOend U8/XfSpa8OoJ5TR8SV3Cu3bECwpbmYlyJ348GKMV0RFtBBgdHtk5QtQkB+AXsEgPuSUS 5MlgTum698vBdj0YX3g7xIStf/faNO2TSK+VgMMps//GbUVkVQ9LJ9ahHs7mHiZcJ6nY lGQWB9hhJ+K7dWWrFOBgUEWkJT/KAbCYF+uzIaZKidKL7XRFY5KvpKaqDHD+Sv4XKK/x 0HUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=nW/L8VcZBCn80T+Kxyr4Dt/TzE3U0N3QD8lxLQvkAAk=; b=ktkKmKMFkgeDYbh/08NzMCg2Ih1YuC0cK+9WlWc42m4A//3VKk13PoFyOnahT5oyez 16hhr0f2zsT62bGme5Byiui0604Q4LFaTU9BdXTNQwmYwBdbJ5jHiTxnqARDbP4TX6Xb ziA4235Zu7RleX1BSaqvjha2X3uSYzHXGJqhPE78xw0F1ALF5uzoFqR33Ac7fg1hkmH4 yUlVl91OX6/qE+RR3uK1vCC7iuf2pdk7v6xfmii+9mp49jWPzuAkxbGoooGlK8Ht3etk Ecia6Pny1FJv96WFVl/Eyf2qP7yKwDeJvlSRmxbSsX3PYVME0svobdPmsM36iUsksPpF dh2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="S5Hfe/92"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 39si1348775edq.195.2020.05.14.01.15.44; Thu, 14 May 2020 01:16:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="S5Hfe/92"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726010AbgENIOR (ORCPT + 99 others); Thu, 14 May 2020 04:14:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725935AbgENIOQ (ORCPT ); Thu, 14 May 2020 04:14:16 -0400 Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87BF3C061A0C; Thu, 14 May 2020 01:14:16 -0700 (PDT) Received: by mail-il1-x142.google.com with SMTP id l20so269957ilj.10; Thu, 14 May 2020 01:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nW/L8VcZBCn80T+Kxyr4Dt/TzE3U0N3QD8lxLQvkAAk=; b=S5Hfe/92gHJ2Kc5wk3x43B4+o6swGaM2Z99CePQdyLGPJPMn30W1UreaPgeaV7cbVx 6Ksj0zhjZIigUVz3G05Ipvagq3eQpb1Q/Q/Tx8tyQa+Y3+yu0Go8cUlgCEqV6W7Cl/13 w0tULc6B16J+R+YpVtDBGL0dmKDdpkX/lRVs2dX0SK5Ff3zLv8WUeueCQedF96giMbNd /6pcYHqFmFrjBvh+QkmsZoYCmdDYs9frT687Ym8rCKaV5JeSURUb2M9GFNDf+CfgHlRj 3gpOiN0aHTJt4SRY/3RyuY/0GLK+031DG3E9DyxAiHEq0GrDJ8iLgIcf7dZVSGgZlVW3 7i/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nW/L8VcZBCn80T+Kxyr4Dt/TzE3U0N3QD8lxLQvkAAk=; b=uUBl6+o/RHM3/5bJzWZqr0Vuil9ByFu3NsDOiBTUI56A81FmhV6g9aU2zil4cf2K06 zl2dXqvHcvGRaDfxw5SMnpzy1Cev0Bs9aPzw8DDbP5OtUTv0zvzL+b2tuC1s52Yav2Cj kVE+e2R4I+V1SigKaVBXKWxfoK5jzgpRXmzPPRB/4LViZG+KrBAvCylroEHaVAksaFy7 rNW47U7r9D4htfInIkmBDQubLjsDwLGSgn2r0TNrZsX7/CzISfHvZeuL2PRhniXt3ugW R5+aZNmlTXl7xge74CUsapZWCaGhn7Vi785RnV7Qv48trAnexe2kMnXbz3p5ru26zPmS P4dQ== X-Gm-Message-State: AOAM531ogXL2IUXX4V41UF0oZaaSaJdEF5Hjep0lMoF45+bGxtVwmQTk 339b4dj8iIIkxfL0TVnJJZF56bHgzvleluen7uk= X-Received: by 2002:a92:84d6:: with SMTP id y83mr1157606ilk.73.1589444055744; Thu, 14 May 2020 01:14:15 -0700 (PDT) MIME-Version: 1.0 References: <20200505153156.925111-1-mic@digikod.net> <20200505153156.925111-3-mic@digikod.net> <202005121407.A339D31A@keescook> In-Reply-To: <202005121407.A339D31A@keescook> From: "Lev R. Oshvang ." Date: Thu, 14 May 2020 11:14:04 +0300 Message-ID: Subject: Re: [PATCH v5 2/6] fs: Add a MAY_EXECMOUNT flag to infer the noexec mount property To: Kees Cook Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , linux-kernel@vger.kernel.org, Aleksa Sarai , Alexei Starovoitov , Al Viro , Andy Lutomirski , Christian Heimes , Daniel Borkmann , Deven Bowers , Eric Chiang , Florian Weimer , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Lakshmi Ramasubramanian , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Mimi Zohar , =?UTF-8?Q?Philippe_Tr=C3=A9buchet?= , Scott Shell , Sean Christopherson , Shuah Khan , Steve Dower , Steve Grubb , Thibaut Sautereau , Vincent Strubel , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-integrity@vger.kernel.org, LSM List , linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 13, 2020 at 12:09 AM Kees Cook wrote: > > On Tue, May 05, 2020 at 05:31:52PM +0200, Micka=C3=ABl Sala=C3=BCn wrote: > > This new MAY_EXECMOUNT flag enables to check if the underlying mount > > point of an inode is marked as executable. This is useful to implement > > a security policy taking advantage of the noexec mount option. > > Security policy is expressed by sysadmin by mount -noexec very clear, I don't think there is a need in sysctl, wish is system-wide > > This flag is set according to path_noexec(), which checks if a mount > > point is mounted with MNT_NOEXEC or if the underlying superblock is > > SB_I_NOEXEC. > > > > Signed-off-by: Micka=C3=ABl Sala=C3=BCn > > Reviewed-by: Philippe Tr=C3=A9buchet > > Reviewed-by: Thibaut Sautereau > > Cc: Aleksa Sarai > > Cc: Al Viro > > Cc: Kees Cook > > --- > > fs/namei.c | 2 ++ > > include/linux/fs.h | 2 ++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/fs/namei.c b/fs/namei.c > > index a320371899cf..33b6d372e74a 100644 > > --- a/fs/namei.c > > +++ b/fs/namei.c > > @@ -2849,6 +2849,8 @@ static int may_open(const struct path *path, int = acc_mode, int flag) > > break; > > } > > > > + /* Pass the mount point executability. */ > > + acc_mode |=3D path_noexec(path) ? 0 : MAY_EXECMOUNT; > > error =3D inode_permission(inode, MAY_OPEN | acc_mode); > > if (error) > > return error; > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index 313c934de9ee..79435fca6c3e 100644 > > --- a/include/linux/fs.h > > +++ b/include/linux/fs.h > > @@ -103,6 +103,8 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff= _t offset, > > #define MAY_NOT_BLOCK 0x00000080 > > /* the inode is opened with O_MAYEXEC */ > > #define MAY_OPENEXEC 0x00000100 > > +/* the mount point is marked as executable */ > > +#define MAY_EXECMOUNT 0x00000200 > > > > /* > > * flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must co= rrespond > > I find this name unintuitive, but I cannot think of anything better, > since I think my problem is that "MAY" doesn't map to the language I > want to use to describe what this flag is indicating. > > Reviewed-by: Kees Cook > > -- > Kees Cook I think that the original patch was perfect, I quite it again @@ -3167,6 +3167,14 @@ static int may_open(struct path *path, int acc_mode, int flag) + + if ((acc_mode & MAY_OPENEXEC) + && (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)) + && (path->mnt && (path->mnt->mnt_flags & MNT_NOEXEC))) + return -EACCES; + + + error =3D inode_permission(inode, MAY_OPEN | acc_mode); As I said in the inline comment above, sysadmin had already express security policy in a very clear way, mount -noexec ! I would only check inside inode_permission() whether the file mode is any ---x permission and deny such open when file is opened with O_MAYEXEC under MNT_NOEXEC mount point New sysctl is indeed required to allow userspace that places scripts or libs under noexec mounts. fs.mnt_noexec_strict =3D0 (allow, e) , 1 (deny any file with --x permission), 2 (deny when O_MAYEXEC absent), for any file with ---x permissions)