lkml.org 
[lkml]   [2022]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v7 0/6] mm/memfd: introduce MFD_NOEXEC_SEAL and MFD_EXEC
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> wrote:
> >
> > 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 their
> > > execute bit set, and the memfd_create() syscall doesn't allow setting
> > > it differently.
> > >
> > > However, in a secure by default system, such as ChromeOS, (where all
> > > executables should come from the rootfs, which is protected by Verified
> > > boot), this executable nature of memfd opens a door for NoExec bypass
> > > and enables “confused deputy attack”. E.g, in VRP bug [1]: cros_vm
> > > process created a memfd to share the content with an external process,
> > > however the memfd is overwritten and used for executing arbitrary code
> > > and root escalation. [2] lists more VRP in this kind.
> > >
> > > On the other hand, executable memfd has its legit use, runc uses memfd’s
> > > 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 behavior of
> > > X bit.For example, if a container has vm.memfd_noexec=2, 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, and
> > 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?

Thanks!

--
Kees Cook

\
 
 \ /
  Last update: 2022-12-15 01:13    [W:1.544 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site