Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221209160453.3246150-1-jeffxu@google.com> <202212141053.7F5D1F6@keescook>
 <CALmYWFss4hGOgJaeah8p7q86xmE7AOwOazxggGCuY=A+ZUVWhQ@mail.gmail.com> <202212141607.D2D986C076@keescook>
In-Reply-To: <202212141607.D2D986C076@keescook>
From:   Jeff Xu <jeffxu@google.com>
Date:   Thu, 15 Dec 2022 08:55:26 -0800
Message-ID: <CALmYWFvJv_4yLxnv=8Bpx0mE_WLi0yGVxR-ybN8VAatEwmM+iQ@mail.gmail.com>
Subject: Re: [PATCH v7 0/6] mm/memfd: introduce MFD_NOEXEC_SEAL and MFD_EXEC
To:     Kees Cook <keescook@chromium.org>
Cc:     akpm@linux-foundation.org, jeffxu@chromium.org,
        skhan@linuxfoundation.org, dmitry.torokhov@gmail.com,
        dverkamp@chromium.org, hughd@google.com, jorgelo@chromium.org,
        linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
        linux-mm@kvack.org, jannh@google.com,
        linux-hardening@vger.kernel.org,
        linux-security-module@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Dec 14, 2022 at 4:08 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Wed, Dec 14, 2022 at 03:32:16PM -0800, Jeff Xu wrote:
> > On Wed, Dec 14, 2022 at 10:54 AM Kees Cook <keescook@chromium.org> wrot=
e:
> > >
> > > On Fri, Dec 09, 2022 at 04:04:47PM +0000, jeffxu@chromium.org wrote:
> > > > From: Jeff Xu <jeffxu@google.com>
> > > >
> > > > Since Linux introduced the memfd feature, memfd have always had the=
ir
> > > > execute bit set, and the memfd_create() syscall doesn't allow setti=
ng
> > > > it differently.
> > > >
> > > > However, in a secure by default system, such as ChromeOS, (where al=
l
> > > > executables should come from the rootfs, which is protected by Veri=
fied
> > > > boot), this executable nature of memfd opens a door for NoExec bypa=
ss
> > > > and enables =E2=80=9Cconfused deputy attack=E2=80=9D.  E.g, in VRP =
bug [1]: cros_vm
> > > > process created a memfd to share the content with an external proce=
ss,
> > > > however the memfd is overwritten and used for executing arbitrary c=
ode
> > > > and root escalation. [2] lists more VRP in this kind.
> > > >
> > > > On the other hand, executable memfd has its legit use, runc uses me=
mfd=E2=80=99s
> > > > seal and executable feature to copy the contents of the binary then
> > > > execute them, for such system, we need a solution to differentiate =
runc's
> > > > use of  executable memfds and an attacker's [3].
> > > >
> > > > To address those above, this set of patches add following:
> > > > 1> Let memfd_create() set X bit at creation time.
> > > > 2> Let memfd to be sealed for modifying X bit.
> > > > 3> A new pid namespace sysctl: vm.memfd_noexec to control the behav=
ior of
> > > >    X bit.For example, if a container has vm.memfd_noexec=3D2, then
> > > >    memfd_create() without MFD_NOEXEC_SEAL will be rejected.
> > > > 4> A new security hook in memfd_create(). This make it possible to =
a new
> > > > LSM, which rejects or allows executable memfd based on its security=
 policy.
> > >
> > > I think patch 1-5 look good to land. The LSM hook seems separable, an=
d
> > > could continue on its own. Thoughts?
> > >
> > Agreed.
> >
> > > (Which tree should memfd change go through?)
> > >
> > I'm not sure, is there a recommendation ?
>
> It looks like it's traditionally through akpm's tree. Andrew, will you
> carry patches 1-5?
>
Hi Andrew, if you are taking this, V8 is the latest that contains patch 1-5=
.

Thanks
Jeff

> Thanks!
>
> --
> Kees Cook