On Tue, Aug 11, 2020 at 12:43:52AM +0200, Mickaël Salaün wrote: > Hooking on open is a simple design that enables processes to check files > they intend to open, before they open them. Which is a good thing, because...? > From an API point of view, > this series extends openat2(2) with one simple flag: O_MAYEXEC. The > enforcement is then subject to the system policy (e.g. mount points, > file access rights, IMA, etc.). That's what "unspecified" means - as far as the kernel concerned, it's "something completely opaque, will let these hooks to play, semantics is entirely up to them". > Checking on open enables to not open a file if it does not meet some > requirements, the same way as if the path doesn't exist or (for whatever > reasons, including execution permission) if access is denied. It is a > good practice to check as soon as possible such properties, and it may > enables to avoid (user space) time-of-check to time-of-use (TOCTOU) > attacks (i.e. misuse of already open resources). ????? You explicitly assume a cooperating caller. If it can't be trusted to issue the check between open and use, or can be manipulated (ptraced, etc.) into not doing so, how can you rely upon the flag having been passed in the first place? And TOCTOU window is definitely not wider that way. If you want to have it done immediately after open(), bloody well do it immediately after open. If attacker has subverted your control flow to the extent that allows them to hit descriptor table in the interval between these two syscalls, you have already lost - they'll simply prevent that flag from being passed. What's the point of burying it inside openat2()? A convenient multiplexor to hook into? We already have one - it's called do_syscall_...
