On Tue, Aug 26, 2025 at 08:30:41AM -0400, Theodore Ts'o wrote: > Is there a single, unified design and requirements document that > describes the threat model, and what you are trying to achieve with > AT_EXECVE_CHECK and O_DENY_WRITE? I've been looking at the cover > letters for AT_EXECVE_CHECK and O_DENY_WRITE, and the documentation > that has landed for AT_EXECVE_CHECK and it really doesn't describe > what *are* the checks that AT_EXECVE_CHECK is trying to achieve: > > "The AT_EXECVE_CHECK execveat(2) flag, and the > SECBIT_EXEC_RESTRICT_FILE and SECBIT_EXEC_DENY_INTERACTIVE > securebits are intended for script interpreters and dynamic linkers > to enforce a consistent execution security policy handled by the > kernel." >From the documentation: 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). > > Um, what security policy? Whether the file is allowed to be executed. This includes file permission, mount point option, ACL, LSM policies... > What checks? Executability checks? > What is a sample exploit > which is blocked by AT_EXECVE_CHECK? Executing/interpreting any data: sh script.txt > > And then on top of it, why can't you do these checks by modifying the > script interpreters? The script interpreter requires modification to use AT_EXECVE_CHECK. There is no other way for user space to reliably check executability of files (taking into account all enforced security policies/configurations).
