linux-stable.git/tools/testing/selftests/exec/Makefile, branch master Linux kernel stable tree selftests/exec: test the pre-opened interpreter limit 2026-08-03T21:36:18+00:00 Christian Brauner brauner@kernel.org 2026-08-03T12:15:01+00:00 f2b69ea2d1a017f0c8e848ff875f4cf2492d2bd0 - an interpreter opened at registration is charged - an interpreter a 'B' entry binds is charged too - an entry that opens none is not - removing an entry gives the charge back - a nested user namespace cannot buy itself budget by raising its own limit Skips where the sysctl or binfmt_misc is missing. The 'B' case lives in binfmt_misc_bpf.c because binding needs a handler. It binds from a child in a user namespace of its own, through the fd the child inherited, so the charge lands on the child while the interpreter is still opened with the entry file's credentials, and nothing outside the child sees a changed limit. Link: https://patch.msgid.link/20260803-work-binfmt_misc-interplimit-v1-2-4a2435500bd9@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> 
- an interpreter opened at registration is charged
- an interpreter a 'B' entry binds is charged too
- an entry that opens none is not
- removing an entry gives the charge back
- a nested user namespace cannot buy itself budget by raising its own limit

Skips where the sysctl or binfmt_misc is missing. The 'B' case lives in
binfmt_misc_bpf.c because binding needs a handler. It binds from a child
in a user namespace of its own, through the fd the child inherited, so
the charge lands on the child while the interpreter is still opened with
the entry file's credentials, and nothing outside the child sees a
changed limit.

Link: https://patch.msgid.link/20260803-work-binfmt_misc-interplimit-v1-2-4a2435500bd9@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
selftests/exec: test interpreters bound to a 'B' entry 2026-08-03T17:15:44+00:00 Christian Brauner brauner@kernel.org 2026-07-30T13:34:10+00:00 7404b1472b111b62f061fc5e9244aacaa862a1e4 One handler, one entry registered disabled, an interpreter per guest architecture bound to a file one write at a time. The load program picks one by name per exec: - an aarch64 binary runs the interpreter bound as "first" and a riscv one the interpreter bound as "second", from a single entry and a single handler - unlinking a bound interpreter and putting a different binary in its place changes nothing, which is what the binding exists for - the entry reports what it bound, under the names it bound them as - a name the entry did not bind fails the exec with -ENOENT rather than falling back to anything - activating the entry refuses further binding with -EBUSY, a later disable does not undo that, and an entry registered without 'D' never accepted a '+' write to begin with - a name binds one interpreter, and control characters are refused - the command has to end at the write, bytes past an embedded nul are refused - an entry binds at most 100 interpreters, the next one is refused with -ENOSPC The test interpreter prints its argv[0], which is the path the kernel ran that copy under, so one binary installed at two paths tells the harness which of them the program picked. Link: https://patch.msgid.link/20260730-work-binfmt_misc-preopen-v1-8-4a0b0da71f16@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> 
One handler, one entry registered disabled, an interpreter per guest
architecture bound to a file one write at a time. The load program picks
one by name per exec:

- an aarch64 binary runs the interpreter bound as "first" and a riscv one
  the interpreter bound as "second", from a single entry and a single
  handler

- unlinking a bound interpreter and putting a different binary in its
  place changes nothing, which is what the binding exists for

- the entry reports what it bound, under the names it bound them as

- a name the entry did not bind fails the exec with -ENOENT rather than
  falling back to anything

- activating the entry refuses further binding with -EBUSY, a later
  disable does not undo that, and an entry registered without 'D' never
  accepted a '+' write to begin with

- a name binds one interpreter, and control characters are refused

- the command has to end at the write, bytes past an embedded nul are
  refused

- an entry binds at most 100 interpreters, the next one is refused with
  -ENOSPC

The test interpreter prints its argv[0], which is the path the kernel ran
that copy under, so one binary installed at two paths tells the harness
which of them the program picked.

Link: https://patch.msgid.link/20260730-work-binfmt_misc-preopen-v1-8-4a0b0da71f16@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
selftests/exec: test registering an entry disabled 2026-08-03T17:15:44+00:00 Christian Brauner brauner@kernel.org 2026-07-30T13:34:05+00:00 6bd0c7aba69873e9944ac8853d167d32c294468c A magic entry registered with 'D' and the same entry without it, to pin down what the flag decides and what it leaves alone: - the entry reports itself disabled and nothing dispatches until '1' is written to it - without 'D' it dispatches straight away - 'D' is not read back among the entry's flags - enabling and disabling afterwards works as it does for any entry - 'D' composes with the flags that shape the invocation - '-1' to the status file removes a staged entry like any other - a file handle held across a removal cannot resurrect the entry Put the entry write and read-back helpers into binfmt_misc_common.h. The bpf suite will need them as well. Link: https://patch.msgid.link/20260730-work-binfmt_misc-preopen-v1-3-4a0b0da71f16@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> 
A magic entry registered with 'D' and the same entry without it, to pin
down what the flag decides and what it leaves alone:

- the entry reports itself disabled and nothing dispatches until '1' is
  written to it

- without 'D' it dispatches straight away

- 'D' is not read back among the entry's flags

- enabling and disabling afterwards works as it does for any entry

- 'D' composes with the flags that shape the invocation

- '-1' to the status file removes a staged entry like any other

- a file handle held across a removal cannot resurrect the entry

Put the entry write and read-back helpers into binfmt_misc_common.h.
The bpf suite will need them as well.

Link: https://patch.msgid.link/20260730-work-binfmt_misc-preopen-v1-3-4a0b0da71f16@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
selftests/exec: check that a binfmt_misc instance cannot be pinned 2026-08-03T08:08:49+00:00 Christian Brauner brauner@kernel.org 2026-07-28T12:26:33+00:00 25757bc855e388eedf86c69c382857ef2c67b08e An 'F' entry whose interpreter keeps the binfmt_misc superblock alive pins the instance that owns it forever. Cover both ways to build that: - an interpreter on the instance's own files, control file and entry file alike - and an instance used as an overlayfs lower layer. Check that an ordinary 'F' registration still succeeds so the fix stays honest about not changing what 'F' promises. Link: https://patch.msgid.link/20260728-work-binfmt_misc-selfpin-v1-2-74df5daeca5b@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> 
An 'F' entry whose interpreter keeps the binfmt_misc superblock alive
pins the instance that owns it forever. Cover both ways to build that:

- an interpreter on the instance's own files, control file and entry
  file alike

- and an instance used as an overlayfs lower layer.

Check that an ordinary 'F' registration still succeeds so the fix stays
honest about not changing what 'F' promises.

Link: https://patch.msgid.link/20260728-work-binfmt_misc-selfpin-v1-2-74df5daeca5b@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
selftests/exec: test binfmt_misc loader substitution 2026-08-03T08:08:47+00:00 Christian Brauner brauner@kernel.org 2026-07-21T14:14:02+00:00 87c50a5855cf0e1a4a42448b2245f6e90df20a4c Exercise the 'L' flag end to end. The payload runs as the main image with a copy of the system loader substituted for its PT_INTERP, and asserts the native identity from inside: - argv exactly as the caller built it - no AT_EXECFD - AT_FLAGS clear - AT_BASE set but outside its own image - AT_PHDR/AT_ENTRY inside it - /proc/self/{exe,comm,stat} and AT_EXECFN all describing the binary - ETXTBSY on the running binary - the substituted loader visible in /proc/self/maps under its real path Magic matching pokes a marker into the ELF header's e_ident padding (EI_PAD, offset 9), which sits inside the match window and is ignored by kernel and loader alike. the same binary is also matched by extension. Two cases cover the paths where the substitution does not happen. A '#!' file that matched an 'L' entry is claimed by binfmt_script rather than by binfmt_elf, so the staged substitute has to be released when the interpreter replaces the file; the test opens the loader for writing afterwards, which fails with ETXTBSY if the write denial was leaked instead. A relative interpreter path is rejected at registration for both 'L' and 'C', neither of which may resolve one against the working directory of whoever runs the binary. The bpf-side BPF_BINPRM_LOADER path shares all machinery past the flag mapping. A harness case for it can join the bpf runtime coverage of the transparent series. Link: https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-20-e57866e4ae0f@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> 
Exercise the 'L' flag end to end. The payload runs as the main image
with a copy of the system loader substituted for its PT_INTERP, and
asserts the native identity from inside:

- argv exactly as the caller built it
- no AT_EXECFD
- AT_FLAGS clear
- AT_BASE set but outside its own image
- AT_PHDR/AT_ENTRY inside it
- /proc/self/{exe,comm,stat} and AT_EXECFN all describing the binary
- ETXTBSY on the running binary
- the substituted loader visible in /proc/self/maps under its real path

Magic matching pokes a marker into the ELF header's e_ident padding
(EI_PAD, offset 9), which sits inside the match window and is ignored by
kernel and loader alike. the same binary is also matched by extension.

Two cases cover the paths where the substitution does not happen. A '#!'
file that matched an 'L' entry is claimed by binfmt_script rather than by
binfmt_elf, so the staged substitute has to be released when the
interpreter replaces the file; the test opens the loader for writing
afterwards, which fails with ETXTBSY if the write denial was leaked
instead. A relative interpreter path is rejected at registration for both
'L' and 'C', neither of which may resolve one against the working
directory of whoever runs the binary.

The bpf-side BPF_BINPRM_LOADER path shares all machinery past the flag
mapping. A harness case for it can join the bpf runtime coverage of
the transparent series.

Link: https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-20-e57866e4ae0f@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
selftests/exec: test the transparent binfmt_misc mode 2026-08-03T08:08:46+00:00 Christian Brauner brauner@kernel.org 2026-07-21T14:13:55+00:00 7baee96f8356fbd01db1dc2641c13104413f6434 Verify the identity a transparent dispatch constructs, from both activation paths. - binfmt_misc_transparent: registers a magic entry with the static 'T' flag and execs a matched binary with arguments. - binfmt_misc_bpf: a handler whose load program sets BPF_BINPRM_TRANSPARENT. Both dispatch to a shared asserting interpreter that runs in place of the binary and checks the contract from the inside: - AT_FLAGS carries AT_FLAGS_TRANSPARENT_INTERP - AT_EXECFD refers to the very inode of the binary - /proc/self/exe resolves to the binary - argv and /proc/self/cmdline are exactly what the caller passed with nothing spliced in - comm is the binary's basename - the binary is write-denied while it runs The static test also validates the registration. 'T' combined with 'P' must be rejected. A kernel that does not know 'T' turns the test into a skip. The asserting interpreter and the static test build without the bpf toolchain so the core transparent semantics stay covered on systems where the bpf cases are skipped. The flag support probe, the canonical payload argv with the run_payload() helper that execs it, and the identity assertions (exe link, comm, write denial) live in binfmt_misc_common.h; the loader substitution test reuses all of them. Link: https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-13-e57866e4ae0f@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> 
Verify the identity a transparent dispatch constructs, from both
activation paths.

- binfmt_misc_transparent: registers a magic entry with the static 'T'
  flag and execs a matched binary with arguments.

- binfmt_misc_bpf: a handler whose load program sets
  BPF_BINPRM_TRANSPARENT.

Both dispatch to a shared asserting interpreter that runs in place of
the binary and checks the contract from the inside:

- AT_FLAGS carries AT_FLAGS_TRANSPARENT_INTERP
- AT_EXECFD refers to the very inode of the binary
- /proc/self/exe resolves to the binary
- argv and /proc/self/cmdline are exactly what the caller passed with
  nothing spliced in
- comm is the binary's basename
- the binary is write-denied while it runs

The static test also validates the registration. 'T' combined with 'P'
must be rejected. A kernel that does not know 'T' turns the test into a
skip. The asserting interpreter and the static test build without the
bpf toolchain so the core transparent semantics stay covered on systems
where the bpf cases are skipped.

The flag support probe, the canonical payload argv with the
run_payload() helper that execs it, and the identity assertions (exe
link, comm, write denial) live in binfmt_misc_common.h; the loader
substitution test reuses all of them.

Link: https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-13-e57866e4ae0f@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
selftests/exec: convert the binfmt_misc bpf test to the kselftest harness 2026-08-03T08:08:45+00:00 Christian Brauner brauner@kernel.org 2026-07-21T14:13:49+00:00 2686010586df2d8d01f44c670c943b3815dedc22 The test reports its own pass and fail lines, returns a bare 4 for KSFT_SKIP and runs both cases in one process, so a failure in the first takes the second with it. It also open-codes the register, unregister, file-copy and mount helpers that the tests for the upcoming transparent and loader dispatch modes need again. Convert it to the kselftest harness: a fixture for the common setup and teardown, one TEST_F per case so each is reported and isolated separately, and SKIP() for the root, BTF and binfmt_misc preconditions. Move the helpers to a shared header on the way, with the register helper preserving the write's errno so a caller can tell a rejected flag combination (EINVAL) from a kernel that does not know the flag at all. The synthetic ELF header gains an e_machine argument and uses the elf.h constants instead of open-coded numbers. The fixture no longer mounts bpffs. The handler is attached with bpf_map__attach_struct_ops() and nothing is ever pinned, the mount was carried along from a bpftool-based draft. The bpf objects are compiled with -DBPF_NO_KFUNC_PROTOTYPES - the guard bpftool emits for exactly this - instead of sed'ing the prototypes out of the generated vmlinux.h. And the config fragment records the options the binfmt_misc tests need so a merge-config kernel can run them. No change in what is tested. Link: https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-7-e57866e4ae0f@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> 
The test reports its own pass and fail lines, returns a bare 4 for
KSFT_SKIP and runs both cases in one process, so a failure in the first
takes the second with it. It also open-codes the register, unregister,
file-copy and mount helpers that the tests for the upcoming transparent
and loader dispatch modes need again.

Convert it to the kselftest harness: a fixture for the common setup and
teardown, one TEST_F per case so each is reported and isolated
separately, and SKIP() for the root, BTF and binfmt_misc preconditions.
Move the helpers to a shared header on the way, with the register
helper preserving the write's errno so a caller can tell a rejected
flag combination (EINVAL) from a kernel that does not know the flag at
all. The synthetic ELF header gains an e_machine argument and uses the
elf.h constants instead of open-coded numbers.

The fixture no longer mounts bpffs. The handler is attached with
bpf_map__attach_struct_ops() and nothing is ever pinned, the mount was
carried along from a bpftool-based draft. The bpf objects are compiled
with -DBPF_NO_KFUNC_PROTOTYPES - the guard bpftool emits for exactly
this - instead of sed'ing the prototypes out of the generated
vmlinux.h. And the config fragment records the options the binfmt_misc
tests need so a merge-config kernel can run them.

No change in what is tested.

Link: https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-7-e57866e4ae0f@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
selftests/exec: add binfmt_misc bpf-backed handler test 2026-08-03T08:08:42+00:00 Farid Zakaria farid.m.zakaria@gmail.com 2026-07-14T19:58:14+00:00 277d787feb2edeb3adae81a99fc47294d523a106 Exercise the bpf-backed ('B') binfmt_misc handlers end to end. A handler is a struct binfmt_misc_ops struct_ops map; the test loads and attaches it (which publishes it by name), activates it with a 'B' entry, and checks that a matched binary is routed to the interpreter the program selected via bpf_binprm_set_interp(). Two self-contained cases are covered: - bpf_interp: the match program matches a synthetic aarch64 ELF header from the prefetched bprm->buf and the load program routes it to a fixed interpreter of its choosing. - nix_origin: the match program parses the program headers to commit only to a "$ORIGIN/..."-relative PT_INTERP and the load program resolves it to an interpreter co-located with the binary -- the relocatable-loader case the kernel ELF loader cannot express. The relocatable binary is linked with PT_INTERP set to the literal "$ORIGIN/binfmt_bpf_interp" (-Wl,--dynamic-linker), which the kernel cannot resolve on its own. Both route to a small test interpreter that prints a marker, proving the program-selected interpreter actually ran. The bpf objects are compiled against the running kernel's BTF: the Makefile generates vmlinux.h with bpftool and the harness links libbpf. Override CLANG/BPFTOOL/VMLINUX_BTF/LIBBPF_CFLAGS/LIBBPF_LDLIBS as needed. The bpf pieces are only built when clang, bpftool, the vmlinux BTF and libbpf are all present (HAVE_BPF_TOOLCHAIN=y forces them) so the other exec selftests keep building without a bpf toolchain. Christian Brauner (Amutable) <brauner@kernel.org> says: Adapted to the two-op contract: 'B' entries carry the handler name in the interpreter field, both programs are sleepable, the match programs decide. nix_origin reads PT_INTERP from the match program and load returns zero on success. Skip on kernels without binfmt_misc_ops in BTF. Build the bpf pieces only when the toolchain is present and gitignore the generated artifacts. Signed-off-by: Farid Zakaria <farid.m.zakaria@gmail.com> Link: https://patch.msgid.link/20260714-work-bpf-binfmt_misc-v2-9-57b7529c002c@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> 
Exercise the bpf-backed ('B') binfmt_misc handlers end to end. A handler
is a struct binfmt_misc_ops struct_ops map; the test loads and attaches
it (which publishes it by name), activates it with a 'B' entry, and
checks that a matched binary is routed to the interpreter the program
selected via bpf_binprm_set_interp().

Two self-contained cases are covered:

  - bpf_interp: the match program matches a synthetic aarch64 ELF header
    from the prefetched bprm->buf and the load program routes it to a
    fixed interpreter of its choosing.
  - nix_origin: the match program parses the program headers to commit
    only to a "$ORIGIN/..."-relative PT_INTERP and the load program
    resolves it to an interpreter co-located with the binary -- the
    relocatable-loader case the kernel ELF loader cannot express. The
    relocatable binary is linked with PT_INTERP set to the literal
    "$ORIGIN/binfmt_bpf_interp" (-Wl,--dynamic-linker), which the kernel
    cannot resolve on its own.

Both route to a small test interpreter that prints a marker, proving the
program-selected interpreter actually ran.

The bpf objects are compiled against the running kernel's BTF: the
Makefile generates vmlinux.h with bpftool and the harness links libbpf.
Override CLANG/BPFTOOL/VMLINUX_BTF/LIBBPF_CFLAGS/LIBBPF_LDLIBS as needed.
The bpf pieces are only built when clang, bpftool, the vmlinux BTF and
libbpf are all present (HAVE_BPF_TOOLCHAIN=y forces them) so the other
exec selftests keep building without a bpf toolchain.

Christian Brauner (Amutable) <brauner@kernel.org> says:

Adapted to the two-op contract: 'B' entries carry the handler name in
the interpreter field, both programs are sleepable, the match programs
decide. nix_origin reads PT_INTERP from the match program and load
returns zero on success. Skip on kernels without binfmt_misc_ops in BTF.
Build the bpf pieces only when the toolchain is present and gitignore
the generated artifacts.

Signed-off-by: Farid Zakaria <farid.m.zakaria@gmail.com>
Link: https://patch.msgid.link/20260714-work-bpf-binfmt_misc-v2-9-57b7529c002c@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
samples/check-exec: Add an enlighten "inc" interpreter and 28 tests 2024-12-19T01:00:29+00:00 Mickaël Salaün mic@digikod.net 2024-12-12T17:42:22+00:00 2a69962be4a7e97ab347e05826480a3352c6fbc8 Add a very simple script interpreter called "inc" that can evaluate two different commands (one per line): - "?" to initialize a counter from user's input; - "+" to increment the counter (which is set to 0 by default). It is enlighten to only interpret executable files according to AT_EXECVE_CHECK and the related securebits: # Executing a script with RESTRICT_FILE is only allowed if the script # is executable: ./set-exec -f -- ./inc script-exec.inc # Allowed ./set-exec -f -- ./inc script-noexec.inc # Denied # Executing stdin with DENY_INTERACTIVE is only allowed if stdin is an # executable regular file: ./set-exec -i -- ./inc -i < script-exec.inc # Allowed ./set-exec -i -- ./inc -i < script-noexec.inc # Denied # However, a pipe is not executable and it is then denied: cat script-noexec.inc | ./set-exec -i -- ./inc -i # Denied # Executing raw data (e.g. command argument) with DENY_INTERACTIVE is # always denied. ./set-exec -i -- ./inc -c "+" # Denied ./inc -c "$(<script-ask.inc)" # Allowed # To directly execute a script, we can update $PATH (used by `env`): PATH="${PATH}:." ./script-exec.inc # To execute several commands passed as argument: Add a complete test suite to check the script interpreter against all possible execution cases: make TARGETS=exec kselftest-install ./tools/testing/selftests/kselftest_install/run_kselftest.sh Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Paul Moore <paul@paul-moore.com> Cc: Serge Hallyn <serge@hallyn.com> Signed-off-by: Mickaël Salaün <mic@digikod.net> Link: https://lore.kernel.org/r/20241212174223.389435-8-mic@digikod.net Signed-off-by: Kees Cook <kees@kernel.org> 
Add a very simple script interpreter called "inc" that can evaluate two
different commands (one per line):
- "?" to initialize a counter from user's input;
- "+" to increment the counter (which is set to 0 by default).

It is enlighten to only interpret executable files according to
AT_EXECVE_CHECK and the related securebits:

  # Executing a script with RESTRICT_FILE is only allowed if the script
  # is executable:
  ./set-exec -f -- ./inc script-exec.inc # Allowed
  ./set-exec -f -- ./inc script-noexec.inc # Denied

  # Executing stdin with DENY_INTERACTIVE is only allowed if stdin is an
  # executable regular file:
  ./set-exec -i -- ./inc -i < script-exec.inc # Allowed
  ./set-exec -i -- ./inc -i < script-noexec.inc # Denied

  # However, a pipe is not executable and it is then denied:
  cat script-noexec.inc | ./set-exec -i -- ./inc -i # Denied

  # Executing raw data (e.g. command argument) with DENY_INTERACTIVE is
  # always denied.
  ./set-exec -i -- ./inc -c "+" # Denied
  ./inc -c "$(<script-ask.inc)" # Allowed

  # To directly execute a script, we can update $PATH (used by `env`):
  PATH="${PATH}:." ./script-exec.inc

  # To execute several commands passed as argument:

Add a complete test suite to check the script interpreter against all
possible execution cases:

  make TARGETS=exec kselftest-install
  ./tools/testing/selftests/kselftest_install/run_kselftest.sh

Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20241212174223.389435-8-mic@digikod.net
Signed-off-by: Kees Cook <kees@kernel.org>
selftests/exec: Add 32 tests for AT_EXECVE_CHECK and exec securebits 2024-12-19T01:00:29+00:00 Mickaël Salaün mic@digikod.net 2024-12-12T17:42:18+00:00 b083cc815376a8ccfba6535b4d59a396b77601d4 Test that checks performed by execveat(..., AT_EXECVE_CHECK) are consistent with noexec mount points and file execute permissions. Test that SECBIT_EXEC_RESTRICT_FILE and SECBIT_EXEC_DENY_INTERACTIVE are inherited by child processes and that they can be pinned with the appropriate SECBIT_EXEC_RESTRICT_FILE_LOCKED and SECBIT_EXEC_DENY_INTERACTIVE_LOCKED bits. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Paul Moore <paul@paul-moore.com> Cc: Serge Hallyn <serge@hallyn.com> Signed-off-by: Mickaël Salaün <mic@digikod.net> Link: https://lore.kernel.org/r/20241212174223.389435-4-mic@digikod.net Signed-off-by: Kees Cook <kees@kernel.org> 
Test that checks performed by execveat(..., AT_EXECVE_CHECK) are
consistent with noexec mount points and file execute permissions.

Test that SECBIT_EXEC_RESTRICT_FILE and SECBIT_EXEC_DENY_INTERACTIVE are
inherited by child processes and that they can be pinned with the
appropriate SECBIT_EXEC_RESTRICT_FILE_LOCKED and
SECBIT_EXEC_DENY_INTERACTIVE_LOCKED bits.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20241212174223.389435-4-mic@digikod.net
Signed-off-by: Kees Cook <kees@kernel.org>