Restrict executing on `memfd`

[sisungo]

We can run executable files that are only given read but not execute access by copying them into a memfd and then call fexecve on the file descriptor. Should we restrict this?

[l0kod]

The initial goal of Landlock is to control access to data, but yes, it makes sense to have more control over an execution environment.

We could leverage the scoped field in struct landlock_ruleset_attr (see #7) and add a dedicated flag to deny memfd execution if it was created in a Landlock domain with such flag set.

[l0kod]

See chromeOS's memfd restriction: chromiumos_bprm_creds_for_exec().

[l0kod]

A more generic approach would be to deny any memory from being mapped as executable, except when mmaping a file with the LANDLOCK_ACCESS_FS_EXECUTE right. This can be implemented with security_mmap_file() and security_file_mprotect().

[sisungo]

A more generic approach would be to deny any memory from being mapped as executable, except when mmaping a file with the LANDLOCK_ACCESS_FS_EXECUTE right. This can be implemented with security_mmap_file() and security_file_mprotect().

That is more generic and powerful, indeed.

[l0kod]

Such an implementation would also change Landlock's hook_file_alloc_security() to remove the LANDLOCK_ACCESS_FS_EXECUTE right by default (when the caller's domain enforces such restriction). A new implementation of the security_bprm_creds_for_exec() hook would then check each FD's executability.

[xandfury]

Hi there! I was looking into memfd related usage b/w apps in Android and somehow ended up here. I believe I can probably take a stab at this 🙂 . Afaik, an additional scope flag, LANDLOCK_SCOPE_MEMFD_EXECUTE can be added. From what I could gather from the docs, the scope pertains to domain-associated IPC restrictions b/w tasks.

As suggested here, memfd restrictions would need to consider both the creating process and the process attempting to execute/map the memory. With security_mmap_file() and security_file_mprotect(), I was thinking of getting the file associated domain (using file->f_cred), and then we can resolve scope using domain_is_scope(current_domain, file_domain, memfd_scope).

Thoughts? @l0kod

[rusty-snake]

Commenting here from a "user" perspective (crablock). Restricting W&X has three domains.

1. memory. Creating W&X memory with mmap/mprotect-family can be blocked with prctl(PR_SET_MDWE, PR_MDWE_REFUSE_EXEC_GAIN).
2. filesystem. Accessing filesystems in a W&X way can be blocked with MOUNT_ATTR_RDONLY/MOUNT_ATTR_NOEXEC or Landlock (even if creating a policy is not trivial with symlinks, bind-mounts, ...).
3. memfd, the thing in-between, 50% memory and 50% filesystem. Creating memfds without MFD_NOEXEC_SEAL can be blocked with seccomp-bpf at the cost of breaking old programs. Or with the pid namespaced vm.memfd_noexec sysctl which at level 2 denies MFD_EXEC and implicitly adds MFD_NOEXEC_SEAL. Unfortunately setting vm.memfd_noexec in a pid-namespace requires CAP_SYS_ADMIN in the initial user-namespace rather than the owning user-namespace. Maybe Landlock could do the same as vm.memfd_noexec=2 but unprivileged, this would keep old programs working.

[xandfury]

I sent in a v1: https://lore.kernel.org/all/[email protected]/

[xandfury]

Hi @l0kod . Any updates on the review? 🙂 Honestly, there is stuff I would change from the patch series. But just wanted your thoughts if I was on the right track or not.

Btw: I had also raised another patch series [1] based on my understanding of how scoping works in landlock. Please have a look at it as well if you get the time 😅

---

[1] - Scoping Abstractions https://lore.kernel.org/all/[email protected]/

[l0kod]

Hi, thanks for the reminder, I'll review them tomorrow.