2018-06-08 00:06:01 +00:00
|
|
|
/*
|
|
|
|
* memfd_create system call and file sealing support
|
|
|
|
*
|
|
|
|
* Code was originally included in shmem.c, and broken out to facilitate
|
|
|
|
* use by hugetlbfs as well as tmpfs.
|
|
|
|
*
|
|
|
|
* This file is released under the GPL.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/vfs.h>
|
|
|
|
#include <linux/pagemap.h>
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/sched/signal.h>
|
|
|
|
#include <linux/khugepaged.h>
|
|
|
|
#include <linux/syscalls.h>
|
|
|
|
#include <linux/hugetlb.h>
|
|
|
|
#include <linux/shmem_fs.h>
|
|
|
|
#include <linux/memfd.h>
|
mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC
The new MFD_NOEXEC_SEAL and MFD_EXEC flags allows application to set
executable bit at creation time (memfd_create).
When MFD_NOEXEC_SEAL is set, memfd is created without executable bit
(mode:0666), and sealed with F_SEAL_EXEC, so it can't be chmod to be
executable (mode: 0777) after creation.
when MFD_EXEC flag is set, memfd is created with executable bit
(mode:0777), this is the same as the old behavior of memfd_create.
The new pid namespaced sysctl vm.memfd_noexec has 3 values:
0: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_EXEC was set.
1: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_NOEXEC_SEAL was set.
2: memfd_create() without MFD_NOEXEC_SEAL will be rejected.
The sysctl allows finer control of memfd_create for old-software that
doesn't set the executable bit, for example, a container with
vm.memfd_noexec=1 means the old-software will create non-executable memfd
by default. Also, the value of memfd_noexec is passed to child namespace
at creation time. For example, if the init namespace has
vm.memfd_noexec=2, all its children namespaces will be created with 2.
[akpm@linux-foundation.org: add stub functions to fix build]
[akpm@linux-foundation.org: remove unneeded register_pid_ns_ctl_table_vm() stub, per Jeff]
[akpm@linux-foundation.org: s/pr_warn_ratelimited/pr_warn_once/, per review]
[akpm@linux-foundation.org: fix CONFIG_SYSCTL=n warning]
Link: https://lkml.kernel.org/r/20221215001205.51969-4-jeffxu@google.com
Signed-off-by: Jeff Xu <jeffxu@google.com>
Co-developed-by: Daniel Verkamp <dverkamp@chromium.org>
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-12-15 00:12:03 +00:00
|
|
|
#include <linux/pid_namespace.h>
|
2018-06-08 00:06:01 +00:00
|
|
|
#include <uapi/linux/memfd.h>
|
|
|
|
|
|
|
|
/*
|
2017-11-22 16:11:31 +00:00
|
|
|
* We need a tag: a new tag would expand every xa_node by 8 bytes,
|
2018-06-08 00:06:01 +00:00
|
|
|
* so reuse a tag which we firmly believe is never set or cleared on tmpfs
|
|
|
|
* or hugetlbfs because they are memory only filesystems.
|
|
|
|
*/
|
|
|
|
#define MEMFD_TAG_PINNED PAGECACHE_TAG_TOWRITE
|
|
|
|
#define LAST_SCAN 4 /* about 150ms max */
|
|
|
|
|
2024-02-26 14:13:23 +00:00
|
|
|
static bool memfd_folio_has_extra_refs(struct folio *folio)
|
|
|
|
{
|
|
|
|
return folio_ref_count(folio) - folio_mapcount(folio) !=
|
|
|
|
folio_nr_pages(folio);
|
|
|
|
}
|
|
|
|
|
2017-11-22 13:37:38 +00:00
|
|
|
static void memfd_tag_pins(struct xa_state *xas)
|
2018-06-08 00:06:01 +00:00
|
|
|
{
|
2024-02-26 14:13:23 +00:00
|
|
|
struct folio *folio;
|
2022-03-05 04:29:01 +00:00
|
|
|
int latency = 0;
|
2018-06-08 00:06:01 +00:00
|
|
|
|
|
|
|
lru_add_drain();
|
|
|
|
|
2017-11-22 13:37:38 +00:00
|
|
|
xas_lock_irq(xas);
|
2024-02-26 14:13:23 +00:00
|
|
|
xas_for_each(xas, folio, ULONG_MAX) {
|
|
|
|
if (!xa_is_value(folio) && memfd_folio_has_extra_refs(folio))
|
2017-11-22 13:37:38 +00:00
|
|
|
xas_set_mark(xas, MEMFD_TAG_PINNED);
|
2018-06-08 00:06:01 +00:00
|
|
|
|
2024-02-26 14:13:23 +00:00
|
|
|
if (++latency < XA_CHECK_SCHED)
|
2017-11-22 13:37:38 +00:00
|
|
|
continue;
|
2022-03-05 04:29:01 +00:00
|
|
|
latency = 0;
|
2017-11-22 13:37:38 +00:00
|
|
|
|
|
|
|
xas_pause(xas);
|
|
|
|
xas_unlock_irq(xas);
|
|
|
|
cond_resched();
|
|
|
|
xas_lock_irq(xas);
|
2018-06-08 00:06:01 +00:00
|
|
|
}
|
2017-11-22 13:37:38 +00:00
|
|
|
xas_unlock_irq(xas);
|
2018-06-08 00:06:01 +00:00
|
|
|
}
|
|
|
|
|
2024-06-24 06:36:11 +00:00
|
|
|
/*
|
|
|
|
* This is a helper function used by memfd_pin_user_pages() in GUP (gup.c).
|
|
|
|
* It is mainly called to allocate a folio in a memfd when the caller
|
|
|
|
* (memfd_pin_folios()) cannot find a folio in the page cache at a given
|
|
|
|
* index in the mapping.
|
|
|
|
*/
|
|
|
|
struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
|
|
|
struct folio *folio;
|
|
|
|
gfp_t gfp_mask;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (is_file_hugepages(memfd)) {
|
|
|
|
/*
|
|
|
|
* The folio would most likely be accessed by a DMA driver,
|
|
|
|
* therefore, we have zone memory constraints where we can
|
|
|
|
* alloc from. Also, the folio will be pinned for an indefinite
|
|
|
|
* amount of time, so it is not expected to be migrated away.
|
|
|
|
*/
|
|
|
|
gfp_mask = htlb_alloc_mask(hstate_file(memfd));
|
|
|
|
gfp_mask &= ~(__GFP_HIGHMEM | __GFP_MOVABLE);
|
|
|
|
|
2024-09-03 14:25:19 +00:00
|
|
|
folio = alloc_hugetlb_folio_reserve(hstate_file(memfd),
|
|
|
|
numa_node_id(),
|
|
|
|
NULL,
|
|
|
|
gfp_mask);
|
2024-06-24 06:36:11 +00:00
|
|
|
if (folio && folio_try_get(folio)) {
|
|
|
|
err = hugetlb_add_to_page_cache(folio,
|
|
|
|
memfd->f_mapping,
|
|
|
|
idx);
|
|
|
|
if (err) {
|
|
|
|
folio_put(folio);
|
|
|
|
free_huge_folio(folio);
|
|
|
|
return ERR_PTR(err);
|
|
|
|
}
|
|
|
|
return folio;
|
|
|
|
}
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
return shmem_read_folio(memfd->f_mapping, idx);
|
|
|
|
}
|
|
|
|
|
2018-06-08 00:06:01 +00:00
|
|
|
/*
|
|
|
|
* Setting SEAL_WRITE requires us to verify there's no pending writer. However,
|
|
|
|
* via get_user_pages(), drivers might have some pending I/O without any active
|
2024-02-26 14:13:23 +00:00
|
|
|
* user-space mappings (eg., direct-IO, AIO). Therefore, we look at all folios
|
2018-06-08 00:06:01 +00:00
|
|
|
* and see whether it has an elevated ref-count. If so, we tag them and wait for
|
|
|
|
* them to be dropped.
|
|
|
|
* The caller must guarantee that no new user will acquire writable references
|
2024-02-26 14:13:23 +00:00
|
|
|
* to those folios to avoid races.
|
2018-06-08 00:06:01 +00:00
|
|
|
*/
|
|
|
|
static int memfd_wait_for_pins(struct address_space *mapping)
|
|
|
|
{
|
2017-11-22 16:11:31 +00:00
|
|
|
XA_STATE(xas, &mapping->i_pages, 0);
|
2024-02-26 14:13:23 +00:00
|
|
|
struct folio *folio;
|
2018-06-08 00:06:01 +00:00
|
|
|
int error, scan;
|
|
|
|
|
2017-11-22 13:37:38 +00:00
|
|
|
memfd_tag_pins(&xas);
|
2018-06-08 00:06:01 +00:00
|
|
|
|
|
|
|
error = 0;
|
|
|
|
for (scan = 0; scan <= LAST_SCAN; scan++) {
|
2022-03-05 04:29:01 +00:00
|
|
|
int latency = 0;
|
2017-11-22 16:11:31 +00:00
|
|
|
|
|
|
|
if (!xas_marked(&xas, MEMFD_TAG_PINNED))
|
2018-06-08 00:06:01 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
if (!scan)
|
|
|
|
lru_add_drain_all();
|
|
|
|
else if (schedule_timeout_killable((HZ << scan) / 200))
|
|
|
|
scan = LAST_SCAN;
|
|
|
|
|
2017-11-22 16:11:31 +00:00
|
|
|
xas_set(&xas, 0);
|
|
|
|
xas_lock_irq(&xas);
|
2024-02-26 14:13:23 +00:00
|
|
|
xas_for_each_marked(&xas, folio, ULONG_MAX, MEMFD_TAG_PINNED) {
|
2017-11-22 16:11:31 +00:00
|
|
|
bool clear = true;
|
2022-03-05 04:29:01 +00:00
|
|
|
|
2024-02-26 14:13:23 +00:00
|
|
|
if (!xa_is_value(folio) &&
|
|
|
|
memfd_folio_has_extra_refs(folio)) {
|
2018-06-08 00:06:01 +00:00
|
|
|
/*
|
|
|
|
* On the last scan, we clean up all those tags
|
|
|
|
* we inserted; but make a note that we still
|
2024-02-26 14:13:23 +00:00
|
|
|
* found folios pinned.
|
2018-06-08 00:06:01 +00:00
|
|
|
*/
|
2017-11-22 16:11:31 +00:00
|
|
|
if (scan == LAST_SCAN)
|
|
|
|
error = -EBUSY;
|
|
|
|
else
|
|
|
|
clear = false;
|
2018-06-08 00:06:01 +00:00
|
|
|
}
|
2017-11-22 16:11:31 +00:00
|
|
|
if (clear)
|
|
|
|
xas_clear_mark(&xas, MEMFD_TAG_PINNED);
|
2022-03-05 04:29:01 +00:00
|
|
|
|
2024-02-26 14:13:23 +00:00
|
|
|
if (++latency < XA_CHECK_SCHED)
|
2017-11-22 16:11:31 +00:00
|
|
|
continue;
|
2022-03-05 04:29:01 +00:00
|
|
|
latency = 0;
|
2018-06-08 00:06:01 +00:00
|
|
|
|
2017-11-22 16:11:31 +00:00
|
|
|
xas_pause(&xas);
|
|
|
|
xas_unlock_irq(&xas);
|
|
|
|
cond_resched();
|
|
|
|
xas_lock_irq(&xas);
|
2018-06-08 00:06:01 +00:00
|
|
|
}
|
2017-11-22 16:11:31 +00:00
|
|
|
xas_unlock_irq(&xas);
|
2018-06-08 00:06:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned int *memfd_file_seals_ptr(struct file *file)
|
|
|
|
{
|
|
|
|
if (shmem_file(file))
|
|
|
|
return &SHMEM_I(file_inode(file))->seals;
|
|
|
|
|
|
|
|
#ifdef CONFIG_HUGETLBFS
|
|
|
|
if (is_file_hugepages(file))
|
|
|
|
return &HUGETLBFS_I(file_inode(file))->seals;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define F_ALL_SEALS (F_SEAL_SEAL | \
|
mm/memfd: add F_SEAL_EXEC
Patch series "mm/memfd: introduce MFD_NOEXEC_SEAL and MFD_EXEC", v8.
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.
This patch (of 5):
The new F_SEAL_EXEC flag will prevent modification of the exec bits:
written as traditional octal mask, 0111, or as named flags, S_IXUSR |
S_IXGRP | S_IXOTH. Any chmod(2) or similar call that attempts to modify
any of these bits after the seal is applied will fail with errno EPERM.
This will preserve the execute bits as they are at the time of sealing, so
the memfd will become either permanently executable or permanently
un-executable.
Link: https://lkml.kernel.org/r/20221215001205.51969-1-jeffxu@google.com
Link: https://lkml.kernel.org/r/20221215001205.51969-2-jeffxu@google.com
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Co-developed-by: Jeff Xu <jeffxu@google.com>
Signed-off-by: Jeff Xu <jeffxu@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: kernel test robot <lkp@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-12-15 00:12:01 +00:00
|
|
|
F_SEAL_EXEC | \
|
2018-06-08 00:06:01 +00:00
|
|
|
F_SEAL_SHRINK | \
|
|
|
|
F_SEAL_GROW | \
|
2019-03-05 23:47:54 +00:00
|
|
|
F_SEAL_WRITE | \
|
|
|
|
F_SEAL_FUTURE_WRITE)
|
2018-06-08 00:06:01 +00:00
|
|
|
|
|
|
|
static int memfd_add_seals(struct file *file, unsigned int seals)
|
|
|
|
{
|
|
|
|
struct inode *inode = file_inode(file);
|
|
|
|
unsigned int *file_seals;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SEALING
|
|
|
|
* Sealing allows multiple parties to share a tmpfs or hugetlbfs file
|
|
|
|
* but restrict access to a specific subset of file operations. Seals
|
|
|
|
* can only be added, but never removed. This way, mutually untrusted
|
|
|
|
* parties can share common memory regions with a well-defined policy.
|
|
|
|
* A malicious peer can thus never perform unwanted operations on a
|
|
|
|
* shared object.
|
|
|
|
*
|
|
|
|
* Seals are only supported on special tmpfs or hugetlbfs files and
|
|
|
|
* always affect the whole underlying inode. Once a seal is set, it
|
|
|
|
* may prevent some kinds of access to the file. Currently, the
|
|
|
|
* following seals are defined:
|
|
|
|
* SEAL_SEAL: Prevent further seals from being set on this file
|
|
|
|
* SEAL_SHRINK: Prevent the file from shrinking
|
|
|
|
* SEAL_GROW: Prevent the file from growing
|
|
|
|
* SEAL_WRITE: Prevent write access to the file
|
mm/memfd: add F_SEAL_EXEC
Patch series "mm/memfd: introduce MFD_NOEXEC_SEAL and MFD_EXEC", v8.
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.
This patch (of 5):
The new F_SEAL_EXEC flag will prevent modification of the exec bits:
written as traditional octal mask, 0111, or as named flags, S_IXUSR |
S_IXGRP | S_IXOTH. Any chmod(2) or similar call that attempts to modify
any of these bits after the seal is applied will fail with errno EPERM.
This will preserve the execute bits as they are at the time of sealing, so
the memfd will become either permanently executable or permanently
un-executable.
Link: https://lkml.kernel.org/r/20221215001205.51969-1-jeffxu@google.com
Link: https://lkml.kernel.org/r/20221215001205.51969-2-jeffxu@google.com
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Co-developed-by: Jeff Xu <jeffxu@google.com>
Signed-off-by: Jeff Xu <jeffxu@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: kernel test robot <lkp@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-12-15 00:12:01 +00:00
|
|
|
* SEAL_EXEC: Prevent modification of the exec bits in the file mode
|
2018-06-08 00:06:01 +00:00
|
|
|
*
|
|
|
|
* As we don't require any trust relationship between two parties, we
|
|
|
|
* must prevent seals from being removed. Therefore, sealing a file
|
|
|
|
* only adds a given set of seals to the file, it never touches
|
|
|
|
* existing seals. Furthermore, the "setting seals"-operation can be
|
|
|
|
* sealed itself, which basically prevents any further seal from being
|
|
|
|
* added.
|
|
|
|
*
|
|
|
|
* Semantics of sealing are only defined on volatile files. Only
|
|
|
|
* anonymous tmpfs and hugetlbfs files support sealing. More
|
|
|
|
* importantly, seals are never written to disk. Therefore, there's
|
|
|
|
* no plan to support it on other file types.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (!(file->f_mode & FMODE_WRITE))
|
|
|
|
return -EPERM;
|
|
|
|
if (seals & ~(unsigned int)F_ALL_SEALS)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
inode_lock(inode);
|
|
|
|
|
|
|
|
file_seals = memfd_file_seals_ptr(file);
|
|
|
|
if (!file_seals) {
|
|
|
|
error = -EINVAL;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (*file_seals & F_SEAL_SEAL) {
|
|
|
|
error = -EPERM;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((seals & F_SEAL_WRITE) && !(*file_seals & F_SEAL_WRITE)) {
|
|
|
|
error = mapping_deny_writable(file->f_mapping);
|
|
|
|
if (error)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
error = memfd_wait_for_pins(file->f_mapping);
|
|
|
|
if (error) {
|
|
|
|
mapping_allow_writable(file->f_mapping);
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-12-15 00:12:04 +00:00
|
|
|
/*
|
|
|
|
* SEAL_EXEC implys SEAL_WRITE, making W^X from the start.
|
|
|
|
*/
|
|
|
|
if (seals & F_SEAL_EXEC && inode->i_mode & 0111)
|
|
|
|
seals |= F_SEAL_SHRINK|F_SEAL_GROW|F_SEAL_WRITE|F_SEAL_FUTURE_WRITE;
|
|
|
|
|
2018-06-08 00:06:01 +00:00
|
|
|
*file_seals |= seals;
|
|
|
|
error = 0;
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
inode_unlock(inode);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int memfd_get_seals(struct file *file)
|
|
|
|
{
|
|
|
|
unsigned int *seals = memfd_file_seals_ptr(file);
|
|
|
|
|
|
|
|
return seals ? *seals : -EINVAL;
|
|
|
|
}
|
|
|
|
|
2023-04-14 15:24:58 +00:00
|
|
|
long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg)
|
2018-06-08 00:06:01 +00:00
|
|
|
{
|
|
|
|
long error;
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case F_ADD_SEALS:
|
|
|
|
error = memfd_add_seals(file, arg);
|
|
|
|
break;
|
|
|
|
case F_GET_SEALS:
|
|
|
|
error = memfd_get_seals(file);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
error = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define MFD_NAME_PREFIX "memfd:"
|
|
|
|
#define MFD_NAME_PREFIX_LEN (sizeof(MFD_NAME_PREFIX) - 1)
|
|
|
|
#define MFD_NAME_MAX_LEN (NAME_MAX - MFD_NAME_PREFIX_LEN)
|
|
|
|
|
mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC
The new MFD_NOEXEC_SEAL and MFD_EXEC flags allows application to set
executable bit at creation time (memfd_create).
When MFD_NOEXEC_SEAL is set, memfd is created without executable bit
(mode:0666), and sealed with F_SEAL_EXEC, so it can't be chmod to be
executable (mode: 0777) after creation.
when MFD_EXEC flag is set, memfd is created with executable bit
(mode:0777), this is the same as the old behavior of memfd_create.
The new pid namespaced sysctl vm.memfd_noexec has 3 values:
0: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_EXEC was set.
1: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_NOEXEC_SEAL was set.
2: memfd_create() without MFD_NOEXEC_SEAL will be rejected.
The sysctl allows finer control of memfd_create for old-software that
doesn't set the executable bit, for example, a container with
vm.memfd_noexec=1 means the old-software will create non-executable memfd
by default. Also, the value of memfd_noexec is passed to child namespace
at creation time. For example, if the init namespace has
vm.memfd_noexec=2, all its children namespaces will be created with 2.
[akpm@linux-foundation.org: add stub functions to fix build]
[akpm@linux-foundation.org: remove unneeded register_pid_ns_ctl_table_vm() stub, per Jeff]
[akpm@linux-foundation.org: s/pr_warn_ratelimited/pr_warn_once/, per review]
[akpm@linux-foundation.org: fix CONFIG_SYSCTL=n warning]
Link: https://lkml.kernel.org/r/20221215001205.51969-4-jeffxu@google.com
Signed-off-by: Jeff Xu <jeffxu@google.com>
Co-developed-by: Daniel Verkamp <dverkamp@chromium.org>
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-12-15 00:12:03 +00:00
|
|
|
#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB | MFD_NOEXEC_SEAL | MFD_EXEC)
|
2018-06-08 00:06:01 +00:00
|
|
|
|
2023-07-05 06:33:14 +00:00
|
|
|
static int check_sysctl_memfd_noexec(unsigned int *flags)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_SYSCTL
|
memfd: replace ratcheting feature from vm.memfd_noexec with hierarchy
This sysctl has the very unusual behaviour of not allowing any user (even
CAP_SYS_ADMIN) to reduce the restriction setting, meaning that if you were
to set this sysctl to a more restrictive option in the host pidns you
would need to reboot your machine in order to reset it.
The justification given in [1] is that this is a security feature and thus
it should not be possible to disable. Aside from the fact that we have
plenty of security-related sysctls that can be disabled after being
enabled (fs.protected_symlinks for instance), the protection provided by
the sysctl is to stop users from being able to create a binary and then
execute it. A user with CAP_SYS_ADMIN can trivially do this without
memfd_create(2):
% cat mount-memfd.c
#include <fcntl.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <linux/mount.h>
#define SHELLCODE "#!/bin/echo this file was executed from this totally private tmpfs:"
int main(void)
{
int fsfd = fsopen("tmpfs", FSOPEN_CLOEXEC);
assert(fsfd >= 0);
assert(!fsconfig(fsfd, FSCONFIG_CMD_CREATE, NULL, NULL, 2));
int dfd = fsmount(fsfd, FSMOUNT_CLOEXEC, 0);
assert(dfd >= 0);
int execfd = openat(dfd, "exe", O_CREAT | O_RDWR | O_CLOEXEC, 0782);
assert(execfd >= 0);
assert(write(execfd, SHELLCODE, strlen(SHELLCODE)) == strlen(SHELLCODE));
assert(!close(execfd));
char *execpath = NULL;
char *argv[] = { "bad-exe", NULL }, *envp[] = { NULL };
execfd = openat(dfd, "exe", O_PATH | O_CLOEXEC);
assert(execfd >= 0);
assert(asprintf(&execpath, "/proc/self/fd/%d", execfd) > 0);
assert(!execve(execpath, argv, envp));
}
% ./mount-memfd
this file was executed from this totally private tmpfs: /proc/self/fd/5
%
Given that it is possible for CAP_SYS_ADMIN users to create executable
binaries without memfd_create(2) and without touching the host filesystem
(not to mention the many other things a CAP_SYS_ADMIN process would be
able to do that would be equivalent or worse), it seems strange to cause a
fair amount of headache to admins when there doesn't appear to be an
actual security benefit to blocking this. There appear to be concerns
about confused-deputy-esque attacks[2] but a confused deputy that can
write to arbitrary sysctls is a bigger security issue than executable
memfds.
/* New API */
The primary requirement from the original author appears to be more based
on the need to be able to restrict an entire system in a hierarchical
manner[3], such that child namespaces cannot re-enable executable memfds.
So, implement that behaviour explicitly -- the vm.memfd_noexec scope is
evaluated up the pidns tree to &init_pid_ns and you have the most
restrictive value applied to you. The new lower limit you can set
vm.memfd_noexec is whatever limit applies to your parent.
Note that a pidns will inherit a copy of the parent pidns's effective
vm.memfd_noexec setting at unshare() time. This matches the existing
behaviour, and it also ensures that a pidns will never have its
vm.memfd_noexec setting *lowered* behind its back (but it will be raised
if the parent raises theirs).
/* Backwards Compatibility */
As the previous version of the sysctl didn't allow you to lower the
setting at all, there are no backwards compatibility issues with this
aspect of the change.
However it should be noted that now that the setting is completely
hierarchical. Previously, a cloned pidns would just copy the current
pidns setting, meaning that if the parent's vm.memfd_noexec was changed it
wouldn't propoagate to existing pid namespaces. Now, the restriction
applies recursively. This is a uAPI change, however:
* The sysctl is very new, having been merged in 6.3.
* Several aspects of the sysctl were broken up until this patchset and
the other patchset by Jeff Xu last month.
And thus it seems incredibly unlikely that any real users would run into
this issue. In the worst case, if this causes userspace isues we could
make it so that modifying the setting follows the hierarchical rules but
the restriction checking uses the cached copy.
[1]: https://lore.kernel.org/CABi2SkWnAgHK1i6iqSqPMYuNEhtHBkO8jUuCvmG3RmUB5TKHJw@mail.gmail.com/
[2]: https://lore.kernel.org/CALmYWFs_dNCzw_pW1yRAo4bGCPEtykroEQaowNULp7svwMLjOg@mail.gmail.com/
[3]: https://lore.kernel.org/CALmYWFuahdUF7cT4cm7_TGLqPanuHXJ-hVSfZt7vpTnc18DPrw@mail.gmail.com/
Link: https://lkml.kernel.org/r/20230814-memfd-vm-noexec-uapi-fixes-v2-4-7ff9e3e10ba6@cyphar.com
Fixes: 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Cc: Dominique Martinet <asmadeus@codewreck.org>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Daniel Verkamp <dverkamp@chromium.org>
Cc: Jeff Xu <jeffxu@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-14 08:41:00 +00:00
|
|
|
struct pid_namespace *ns = task_active_pid_ns(current);
|
|
|
|
int sysctl = pidns_memfd_noexec_scope(ns);
|
2023-07-05 06:33:14 +00:00
|
|
|
|
|
|
|
if (!(*flags & (MFD_EXEC | MFD_NOEXEC_SEAL))) {
|
2023-08-14 08:40:58 +00:00
|
|
|
if (sysctl >= MEMFD_NOEXEC_SCOPE_NOEXEC_SEAL)
|
2023-07-05 06:33:14 +00:00
|
|
|
*flags |= MFD_NOEXEC_SEAL;
|
|
|
|
else
|
|
|
|
*flags |= MFD_EXEC;
|
|
|
|
}
|
|
|
|
|
2023-08-14 08:40:58 +00:00
|
|
|
if (!(*flags & MFD_NOEXEC_SEAL) && sysctl >= MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED) {
|
|
|
|
pr_err_ratelimited(
|
|
|
|
"%s[%d]: memfd_create() requires MFD_NOEXEC_SEAL with vm.memfd_noexec=%d\n",
|
|
|
|
current->comm, task_pid_nr(current), sysctl);
|
2023-07-05 06:33:14 +00:00
|
|
|
return -EACCES;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-06-08 00:06:01 +00:00
|
|
|
SYSCALL_DEFINE2(memfd_create,
|
|
|
|
const char __user *, uname,
|
|
|
|
unsigned int, flags)
|
|
|
|
{
|
|
|
|
unsigned int *file_seals;
|
|
|
|
struct file *file;
|
|
|
|
int fd, error;
|
|
|
|
char *name;
|
|
|
|
long len;
|
|
|
|
|
|
|
|
if (!(flags & MFD_HUGETLB)) {
|
|
|
|
if (flags & ~(unsigned int)MFD_ALL_FLAGS)
|
|
|
|
return -EINVAL;
|
|
|
|
} else {
|
|
|
|
/* Allow huge page size encoding in flags. */
|
|
|
|
if (flags & ~(unsigned int)(MFD_ALL_FLAGS |
|
|
|
|
(MFD_HUGE_MASK << MFD_HUGE_SHIFT)))
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC
The new MFD_NOEXEC_SEAL and MFD_EXEC flags allows application to set
executable bit at creation time (memfd_create).
When MFD_NOEXEC_SEAL is set, memfd is created without executable bit
(mode:0666), and sealed with F_SEAL_EXEC, so it can't be chmod to be
executable (mode: 0777) after creation.
when MFD_EXEC flag is set, memfd is created with executable bit
(mode:0777), this is the same as the old behavior of memfd_create.
The new pid namespaced sysctl vm.memfd_noexec has 3 values:
0: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_EXEC was set.
1: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_NOEXEC_SEAL was set.
2: memfd_create() without MFD_NOEXEC_SEAL will be rejected.
The sysctl allows finer control of memfd_create for old-software that
doesn't set the executable bit, for example, a container with
vm.memfd_noexec=1 means the old-software will create non-executable memfd
by default. Also, the value of memfd_noexec is passed to child namespace
at creation time. For example, if the init namespace has
vm.memfd_noexec=2, all its children namespaces will be created with 2.
[akpm@linux-foundation.org: add stub functions to fix build]
[akpm@linux-foundation.org: remove unneeded register_pid_ns_ctl_table_vm() stub, per Jeff]
[akpm@linux-foundation.org: s/pr_warn_ratelimited/pr_warn_once/, per review]
[akpm@linux-foundation.org: fix CONFIG_SYSCTL=n warning]
Link: https://lkml.kernel.org/r/20221215001205.51969-4-jeffxu@google.com
Signed-off-by: Jeff Xu <jeffxu@google.com>
Co-developed-by: Daniel Verkamp <dverkamp@chromium.org>
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-12-15 00:12:03 +00:00
|
|
|
/* Invalid if both EXEC and NOEXEC_SEAL are set.*/
|
|
|
|
if ((flags & MFD_EXEC) && (flags & MFD_NOEXEC_SEAL))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2023-08-14 08:40:58 +00:00
|
|
|
error = check_sysctl_memfd_noexec(&flags);
|
|
|
|
if (error < 0)
|
|
|
|
return error;
|
2023-07-05 06:33:14 +00:00
|
|
|
|
2018-06-08 00:06:01 +00:00
|
|
|
/* length includes terminating zero */
|
|
|
|
len = strnlen_user(uname, MFD_NAME_MAX_LEN + 1);
|
|
|
|
if (len <= 0)
|
|
|
|
return -EFAULT;
|
|
|
|
if (len > MFD_NAME_MAX_LEN + 1)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
name = kmalloc(len + MFD_NAME_PREFIX_LEN, GFP_KERNEL);
|
|
|
|
if (!name)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
strcpy(name, MFD_NAME_PREFIX);
|
|
|
|
if (copy_from_user(&name[MFD_NAME_PREFIX_LEN], uname, len)) {
|
|
|
|
error = -EFAULT;
|
|
|
|
goto err_name;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* terminating-zero may have changed after strnlen_user() returned */
|
|
|
|
if (name[len + MFD_NAME_PREFIX_LEN - 1]) {
|
|
|
|
error = -EFAULT;
|
|
|
|
goto err_name;
|
|
|
|
}
|
|
|
|
|
|
|
|
fd = get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0);
|
|
|
|
if (fd < 0) {
|
|
|
|
error = fd;
|
|
|
|
goto err_name;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (flags & MFD_HUGETLB) {
|
2021-11-09 02:31:27 +00:00
|
|
|
file = hugetlb_file_setup(name, 0, VM_NORESERVE,
|
2018-06-08 00:06:01 +00:00
|
|
|
HUGETLB_ANONHUGE_INODE,
|
|
|
|
(flags >> MFD_HUGE_SHIFT) &
|
|
|
|
MFD_HUGE_MASK);
|
|
|
|
} else
|
|
|
|
file = shmem_file_setup(name, 0, VM_NORESERVE);
|
|
|
|
if (IS_ERR(file)) {
|
|
|
|
error = PTR_ERR(file);
|
|
|
|
goto err_fd;
|
|
|
|
}
|
|
|
|
file->f_mode |= FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE;
|
2018-07-11 18:19:04 +00:00
|
|
|
file->f_flags |= O_LARGEFILE;
|
2018-06-08 00:06:01 +00:00
|
|
|
|
mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC
The new MFD_NOEXEC_SEAL and MFD_EXEC flags allows application to set
executable bit at creation time (memfd_create).
When MFD_NOEXEC_SEAL is set, memfd is created without executable bit
(mode:0666), and sealed with F_SEAL_EXEC, so it can't be chmod to be
executable (mode: 0777) after creation.
when MFD_EXEC flag is set, memfd is created with executable bit
(mode:0777), this is the same as the old behavior of memfd_create.
The new pid namespaced sysctl vm.memfd_noexec has 3 values:
0: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_EXEC was set.
1: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_NOEXEC_SEAL was set.
2: memfd_create() without MFD_NOEXEC_SEAL will be rejected.
The sysctl allows finer control of memfd_create for old-software that
doesn't set the executable bit, for example, a container with
vm.memfd_noexec=1 means the old-software will create non-executable memfd
by default. Also, the value of memfd_noexec is passed to child namespace
at creation time. For example, if the init namespace has
vm.memfd_noexec=2, all its children namespaces will be created with 2.
[akpm@linux-foundation.org: add stub functions to fix build]
[akpm@linux-foundation.org: remove unneeded register_pid_ns_ctl_table_vm() stub, per Jeff]
[akpm@linux-foundation.org: s/pr_warn_ratelimited/pr_warn_once/, per review]
[akpm@linux-foundation.org: fix CONFIG_SYSCTL=n warning]
Link: https://lkml.kernel.org/r/20221215001205.51969-4-jeffxu@google.com
Signed-off-by: Jeff Xu <jeffxu@google.com>
Co-developed-by: Daniel Verkamp <dverkamp@chromium.org>
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-12-15 00:12:03 +00:00
|
|
|
if (flags & MFD_NOEXEC_SEAL) {
|
|
|
|
struct inode *inode = file_inode(file);
|
|
|
|
|
|
|
|
inode->i_mode &= ~0111;
|
|
|
|
file_seals = memfd_file_seals_ptr(file);
|
2023-06-07 13:24:27 +00:00
|
|
|
if (file_seals) {
|
|
|
|
*file_seals &= ~F_SEAL_SEAL;
|
|
|
|
*file_seals |= F_SEAL_EXEC;
|
|
|
|
}
|
mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC
The new MFD_NOEXEC_SEAL and MFD_EXEC flags allows application to set
executable bit at creation time (memfd_create).
When MFD_NOEXEC_SEAL is set, memfd is created without executable bit
(mode:0666), and sealed with F_SEAL_EXEC, so it can't be chmod to be
executable (mode: 0777) after creation.
when MFD_EXEC flag is set, memfd is created with executable bit
(mode:0777), this is the same as the old behavior of memfd_create.
The new pid namespaced sysctl vm.memfd_noexec has 3 values:
0: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_EXEC was set.
1: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
MFD_NOEXEC_SEAL was set.
2: memfd_create() without MFD_NOEXEC_SEAL will be rejected.
The sysctl allows finer control of memfd_create for old-software that
doesn't set the executable bit, for example, a container with
vm.memfd_noexec=1 means the old-software will create non-executable memfd
by default. Also, the value of memfd_noexec is passed to child namespace
at creation time. For example, if the init namespace has
vm.memfd_noexec=2, all its children namespaces will be created with 2.
[akpm@linux-foundation.org: add stub functions to fix build]
[akpm@linux-foundation.org: remove unneeded register_pid_ns_ctl_table_vm() stub, per Jeff]
[akpm@linux-foundation.org: s/pr_warn_ratelimited/pr_warn_once/, per review]
[akpm@linux-foundation.org: fix CONFIG_SYSCTL=n warning]
Link: https://lkml.kernel.org/r/20221215001205.51969-4-jeffxu@google.com
Signed-off-by: Jeff Xu <jeffxu@google.com>
Co-developed-by: Daniel Verkamp <dverkamp@chromium.org>
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-12-15 00:12:03 +00:00
|
|
|
} else if (flags & MFD_ALLOW_SEALING) {
|
|
|
|
/* MFD_EXEC and MFD_ALLOW_SEALING are set */
|
2018-06-08 00:06:01 +00:00
|
|
|
file_seals = memfd_file_seals_ptr(file);
|
2023-06-07 13:24:27 +00:00
|
|
|
if (file_seals)
|
|
|
|
*file_seals &= ~F_SEAL_SEAL;
|
2018-06-08 00:06:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fd_install(fd, file);
|
|
|
|
kfree(name);
|
|
|
|
return fd;
|
|
|
|
|
|
|
|
err_fd:
|
|
|
|
put_unused_fd(fd);
|
|
|
|
err_name:
|
|
|
|
kfree(name);
|
|
|
|
return error;
|
|
|
|
}
|