AT_EXECVE_CHECK Submitted For Linux 6.14 To Help With Consistent Security

Written by Michael Larabel in Linux Kernel on 16 January 2025 at 06:55 AM EST. Add A Comment
LINUX KERNEL
In anticipation of the Linux 6.14 merge window opening next week if Linux 6.13 releases as expected this coming Sunday, Google engineer Kees Cook has already sent out pull requests to Linus Torvalds of new feature code he's been aligning for the v6.14 cycle. One of the interesting pulls is the introduction of the AT_EXECVE_CHECK flag to the execveat call.

AT_EXECVE_CHECK is believed baked and ready for Linux 6.14 barring any objections from Linus Torvalds. AT_EXECVE_CHECK spent the past cycle in "-next" and aims to offer more consistent security on Linux by allowing user-space with a means of "execability" checks for things that aren't executable but don't pass through execve, such as scripts run by an interpreter in user-space or dlopen()'ed libraries.

Using the AT_EXECVE_CHECK flag with execveat checks to see if a file would be allowed for execution such as for script interpreters and dynamic linkers to check the execution permission per the Linux kernel's security policy. Another designed use-case is adding more information to access logs.

AT_EXECVE_CHECK


The documentation of this executability check option adds:
"Passing the AT_EXECVE_CHECK flag to execveat(2) only performs a check on a regular file and returns 0 if execution of this file would be allowed, ignoring the file format and then the related interpreter dependencies (e.g. ELF libraries, script's shebang).

Programs should always perform this check to apply kernel-level checks against files that are not directly executed by the kernel but passed to a user space interpreter instead. All files that contain executable code, from the point of view of the interpreter, should be checked. However the result of this check should only be enforced according to SECBIT_EXEC_RESTRICT_FILE or SECBIT_EXEC_DENY_INTERACTIVE.

The main purpose of this flag is to improve the security and consistency of an execution environment to ensure that direct file execution (e.g. ./script.sh) and indirect file execution (e.g. sh script.sh) lead to the same result. For instance, this can be used to check if a file is trustworthy according to the caller's environment.

In a secure environment, libraries and any executable dependencies should also be checked. For instance, dynamic linking should make sure that all libraries are allowed for execution to avoid trivial bypass (e.g. using LD_PRELOAD). For such secure execution environment to make sense, only trusted code should be executable, which also requires integrity guarantees.

To avoid race conditions leading to time-of-check to time-of-use issues, AT_EXECVE_CHECK should be used with AT_EMPTY_PATH to check against a file descriptor instead of a path."

This pull request is now awaiting action by Linus Torvalds once the Linux 6.14 merge window opens for introducing AT_EXECVE_CHECK.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week