Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC)

From: Mickaël Salaün
Date: Tue Apr 05 2022 - 19:27:37 EST

On 05/04/2022 00:25, Kees Cook wrote:
On Mon, Apr 04, 2022 at 02:28:19PM -0700, Linus Torvalds wrote:
Now, what I *think* you mean is

(1) user-space executable loaders want to be able to test the *same*
policy as the kernel does for execve()

Right. The script interpreter wants to ask "if this file were actually
an ELF going through execve(), would the kernel allow it?"

The current behavior was a bit more flexible thanks to the sysctl. It was either the mount exec option check, the file perm check or both. The rationale is to let sysadmins adapt their system to existing applications/interpreters without breaking. Only basing the check on mount exec and file perm could be an issue in the short term, but I guess it would deter inconsistencies in existing systems… I'm not sure it is a wise move because if no interpreter want to use this check it would then be useless. See commit message in and the trusted_for_policy sysctl documentation:

"Even without enforced security policy, user space interpreters can use
this syscall to try as much as possible to enforce the system policy at
their level, knowing that it will not break anything on running systems
which do not care about this feature. However, on systems which want
this feature enforced, there will be knowledgeable people (i.e. system
administrator who configured fs.trusted_for_policy deliberately) to
manage it. [...]"

(2) access(path, EXECVE_OK) will do the same permission checks as
"execve()" would do for that path

Maybe. I defer to Mickaël here, but my instinct is to avoid creating an
API that can be accidentally misused. I'd like this to be fd-only based,
since that removes path name races. (e.g. trusted_for() required an fd.)

The fd-based approach is definitely better from a security point of view but there is indeed a use case for pathnames. I guess we could highlight this point in the documentation.

(3) if you already have the fd open, use "faccess(fd, NULL,

Yes, specifically faccessat2(). (And continuing the race thought above,
yes, there could still be races if the content of the file could be
changed, but that case is less problematic under real-world conditions.)

I'm not worried about changes in the file once it is opened. This could be an issue but not in the kernel (e.g. flaky update system).