Message-ID: <20251120.KuoC9rol6aht@digikod.net>
Date: Thu, 20 Nov 2025 16:42:13 +0100
From: Mickaël Salaün <mic@...ikod.net>
To: Abhinav Saxena <xandfury@...il.com>
Cc: Günther Noack <gnoack@...gle.com>, 
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, 
	"Serge E. Hallyn" <serge@...lyn.com>, Shuah Khan <shuah@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <nick.desaulniers+lkml@...il.com>, 
	Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, 
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	llvm@...ts.linux.dev, Daniel Verkamp <dverkamp@...omium.org>, 
	Jeff Xu <jeffxu@...omium.org>, Thiébaud Weksteen <tweek@...gle.com>, 
	Stephen Smalley <stephen.smalley.work@...il.com>
Subject: Re: [PATCH RFC 0/4] landlock: add LANDLOCK_SCOPE_MEMFD_EXEC execution

On Sun, Sep 28, 2025 at 05:37:02PM -0600, Abhinav Saxena wrote:
> Thanks for the detailed reply Mickaël!
> 
> Mickaël Salaün <mic@...ikod.net> writes:
> 
> > Thanks for this patch series Abhinav!  The code looks good overall, but
> > we should clarify the design.  Sorry for the delayed response, it is on
> > my radar now.

Please feel free to ping me after two weeks without answer, I might miss
some emails.

> >
> > CCing Jeff and Daniel
> >
> > On Sat, Jul 19, 2025 at 05:13:10AM -0600, Abhinav Saxena wrote:
> >> This patch series introduces LANDLOCK_SCOPE_MEMFD_EXEC, a new Landlock
> >> scoping mechanism that restricts execution of anonymous memory file
> >> descriptors (memfd) created via memfd_create(2). This addresses security
> >> gaps where processes can bypass W^X policies and execute arbitrary code
> >> through anonymous memory objects.
> >> 
> >> Fixes: <https://github.com/landlock-lsm/linux/issues/37>
> >> 
> >> SECURITY PROBLEM
> >> `=============='
> >> 
> >> Current Landlock filesystem restrictions do not cover memfd objects,
> >> allowing processes to:
> >> 
> >> 1. Read-to-execute bypass: Create writable memfd, inject code,
> >>    then execute via mmap(PROT_EXEC) or direct execve()
> >> 2. Anonymous execution: Execute code without touching the filesystem via
> >>    execve(“/proc/self/fd/N”) where N is a memfd descriptor
> >
> >> 3. Cross-domain access violations: Pass memfd between processes to
> >>    bypass domain restrictions
> >
> > Landlock only restricts access at open time, which is a useful property.
> > This enables to create more restricted sandboxes but still get access to
> > outside resources via trusted processes.  If the process passing the FDs
> > is not trusted, the sandboxed process could just ask to execute
> > arbitrary code outside the sandbox anyway.
> >
> > However, the Landlock scopes are designed to block IPC from within a
> > sandbox to outside the sandbox.  We could have a new scope to forbid a
> > sandbox process to receive or inherit file descriptors, but that would
> > be a different and generic feature.  For compatibility reasons, this
> > might not be easy to implement and I think there are more important
> > features to implement before that.
> >
> > Thinking more about it, restricting memfd should not be a “scoped” flag
> > because the semantic is not the same, but we should have a new ruleset
> > property instead, something like “ruleset.denied” with a related
> > LANDLOCK_DENY_EXECUTE_MEMFD flag.  This flag will only have an impact on
> > newly created memfd from a sandboxed process with this restriction at
> > creation time. This could be implemented with hook_file_alloc_security()
> > by checking if the file is indeed a memfd and checking inode->i_mode for
> > executability bits (which would imply MFD_NOEXEC_SEAL).
> >
> 
> Thanks for the clarification! So if I understood correctly we are
> proposing adding a `denied` field to the `landlock_ruleset_attr` struct
> 
> struct landlock_ruleset_attr {
>     __u64 handled_access_fs;
>     __u64 handled_access_net;
>     __u64 scoped;
>     __u64 denied;              /* New field */
> };
> 
> which allows memfd_create() to be allowed by default unless
> LANDLOCK_DENY_EXECUTE_MEMFD bit is set.

Yes

> Also it seems Thiébaud
> Weksteen’s patch[1] will land, and maybe we can use
> security_inode_init_security_anon instead? What do you think?

Definitely, and this patch is now merged in -next.

> 
> Apologies for my ignorance, do we have to wait till his patch has
> landed into Linus’s tree?

As long as you explain this dependency in the commit message and point
to the patch (as a comment, after a "---" line), we're good.

> 
> >> 
> >> These scenarios can occur in sandboxed environments where filesystem
> >> access is restricted but memfd creation remains possible.
> >> 
> >> IMPLEMENTATION
> >> `============'
> >> 
> >> The implementation adds hierarchical execution control through domain
> >> scoping:
> >> 
> >> Core Components:
> >> - is_memfd_file(): Reliable memfd detection via “memfd:” dentry prefix
> >> - domain_is_scoped(): Cross-domain hierarchy checking (moved to domain.c)
> >> - LSM hooks: mmap_file, file_mprotect, bprm_creds_for_exec
> >> - Creation-time restrictions: hook_file_alloc_security
> >> 
> >> Security Matrix:
> >> Execution decisions follow domain hierarchy rules preventing both
> >> same-domain bypass attempts and cross-domain access violations while
> >> preserving legitimate hierarchical access patterns.
> >> 
> >> Domain Hierarchy with LANDLOCK_SCOPE_MEMFD_EXEC:
> >> `============================================='
> >> 
> >> Root (no domain) - No restrictions
> >>   |
> >>   +– Domain A [SCOPE_MEMFD_EXEC] Layer 1
> >>   |     +– memfd_A (tagged with Domain A as creator)
> >>   |     |
> >>   |     +– Domain A1 (child) [NO SCOPE] Layer 2
> >>   |     |     +– Inherits Layer 1 restrictions from parent
> >>   |     |     +– memfd_A1 (can create, inherits restrictions)
> >>   |     |     +– Domain A1a [SCOPE_MEMFD_EXEC] Layer 3
> >>   |     |           +– memfd_A1a (tagged with Domain A1a)
> >>   |     |
> >>   |     +– Domain A2 (child) [SCOPE_MEMFD_EXEC] Layer 2
> >>   |           +– memfd_A2 (tagged with Domain A2 as creator)
> >>   |           +– CANNOT access memfd_A1 (different subtree)
> >>   |
> >>   +– Domain B [SCOPE_MEMFD_EXEC] Layer 1
> >>         +– memfd_B (tagged with Domain B as creator)
> >>         +– CANNOT access ANY memfd from Domain A subtree
> >> 
> >> Execution Decision Matrix:
> >> `======================'
> >> Executor->  |  A  | A1 | A1a | A2 | B  | Root
> >> Creator     |     |    |     |    |    |
> >> ————|—–|—-|—–|—-|—-|—–
> >> Domain A    |  X  | X  | X   | X  | X  |  Y
> >> Domain A1   |  Y  | X  | X   | X  | X  |  Y
> >> Domain A1a  |  Y  | Y  | X   | X  | X  |  Y
> >> Domain A2   |  Y  | X  | X   | X  | X  |  Y
> >> Domain B    |  X  | X  | X   | X  | X  |  Y
> >> Root        |  Y  | Y  | Y   | Y  | Y  |  Y
> >> 
> >> Legend: Y = Execution allowed, X = Execution denied
> >
> > Because checks should not be related to scopes, this will be much
> > simpler.
> >
> >> 
> >> Scenarios Covered:
> >> - Direct mmap(PROT_EXEC) on memfd files
> >> - Two-stage mmap(PROT_READ) + mprotect(PROT_EXEC) bypass attempts
> >> - execve("/proc/self/fd/N") anonymous execution
> >> - execveat() and fexecve() file descriptor execution
> >> - Cross-process memfd inheritance and IPC passing
> >> 
> >> TESTING
> >> `====='
> >> 
> >> All patches have been validated with:
> >> - scripts/checkpatch.pl –strict (clean)
> >> - Selftests covering same-domain restrictions, cross-domain 
> >>   hierarchy enforcement, and regular file isolation
> >> - KUnit tests for memfd detection edge cases
> >
> > Thanks for all these tests!
> >
> >> 
> >> DISCLAIMER
> >> `========'
> >> 
> >> My understanding of Landlock scoping semantics may be limited, but this
> >> implementation reflects my current understanding based on available
> >> documentation and code analysis. I welcome feedback and corrections
> >> regarding the scoping logic and domain hierarchy enforcement.
> >> 
> >> Signed-off-by: Abhinav Saxena <xandfury@...il.com>
> >> —
> >> Abhinav Saxena (4):
> >>       landlock: add LANDLOCK_SCOPE_MEMFD_EXEC scope
> >>       landlock: implement memfd detection
> >>       landlock: add memfd exec LSM hooks and scoping
> >>       selftests/landlock: add memfd execution tests
> >> 
> >>  include/uapi/linux/landlock.h                      |   5 +
> >>  security/landlock/.kunitconfig                     |   1 +
> >>  security/landlock/audit.c                          |   4 +
> >>  security/landlock/audit.h                          |   1 +
> >>  security/landlock/cred.c                           |  14 -
> >>  security/landlock/domain.c                         |  67 ++++
> >>  security/landlock/domain.h                         |   4 +
> >>  security/landlock/fs.c                             | 405 ++++++++++++++++++++-
> >>  security/landlock/limits.h                         |   2 +-
> >>  security/landlock/task.c                           |  67 —-
> >>  …/selftests/landlock/scoped_memfd_exec_test.c    | 325 +++++++++++++++++
> >>  11 files changed, 812 insertions(+), 83 deletions(-)
> >> —
> >> base-commit: 5b74b2eff1eeefe43584e5b7b348c8cd3b723d38
> >> change-id: 20250716-memfd-exec-ac0d582018c3
> >> 
> >> Best regards,
> >> – 
> >> Abhinav Saxena <xandfury@...il.com>
> >> 
> >> 
> 
> Best,
> Abhinav
> 
> [1] - <https://lore.kernel.org/all/20250918020434.1612137-1-tweek@google.com/>

Powered by blists - more mailing lists