Date: Tue, 11 Aug 2020 10:49:24 +0200 From: Mickaël Salaün <mic@...ikod.net> To: Al Viro <viro@...iv.linux.org.uk> 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 11/08/2020 01:05, Al Viro wrote: > 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". I see it as an access controls mechanism; access may be granted or denied, as for O_RDONLY, O_WRONLY or (non-Linux) O_EXEC. Even for common access controls, there are capabilities to bypass them (i.e. CAP_DAC_OVERRIDE), but multiple layers may enforce different complementary policies. > >> 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. As said in the below (removed) reply, no, quite the contrary. > 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. OK, I guess it would be considered a bug in the application (e.g. buggy resource management between threads). > > 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_... > To check as soon as possible without opening something that should not be opened in the first place. Isn't a dedicated syscall a bit too much for this feature? What about adding a new command/flag to fcntl(2)?
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.