Date: Tue, 11 Aug 2020 00:05:21 +0100 From: Al Viro <viro@...iv.linux.org.uk> To: Mickaël Salaün <mic@...ikod.net> Cc: Kees Cook <keescook@...omium.org>, Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org, Aleksa Sarai <cyphar@...har.com>, Alexei Starovoitov <ast@...nel.org>, Andy Lutomirski <luto@...nel.org>, Christian Brauner <christian.brauner@...ntu.com>, Christian Heimes <christian@...hon.org>, Daniel Borkmann <daniel@...earbox.net>, Deven Bowers <deven.desai@...ux.microsoft.com>, Dmitry Vyukov <dvyukov@...gle.com>, Eric Biggers <ebiggers@...nel.org>, Eric Chiang <ericchiang@...gle.com>, Florian Weimer <fweimer@...hat.com>, James Morris <jmorris@...ei.org>, Jan Kara <jack@...e.cz>, Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>, Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>, Matthew Garrett <mjg59@...gle.com>, Matthew Wilcox <willy@...radead.org>, Michael Kerrisk <mtk.manpages@...il.com>, Mimi Zohar <zohar@...ux.ibm.com>, Philippe Trébuchet <philippe.trebuchet@....gouv.fr>, Scott Shell <scottsh@...rosoft.com>, Sean Christopherson <sean.j.christopherson@...el.com>, Shuah Khan <shuah@...nel.org>, Steve Dower <steve.dower@...hon.org>, Steve Grubb <sgrubb@...hat.com>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, Thibaut Sautereau <thibaut.sautereau@...p-os.org>, Vincent Strubel <vincent.strubel@....gouv.fr>, kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org, linux-integrity@...r.kernel.org, linux-security-module@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [PATCH v7 0/7] Add support for O_MAYEXEC 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_...
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.