linux-kernel - Re: [RFC PATCH v19 1/5] exec: Add a new AT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a0da7702-dabe-49e4-87f4-5d6111f023a8@python.org>
Date: Wed, 17 Jul 2024 09:26:22 +0100
From: Steve Dower <steve.dower@...hon.org>
To: Jeff Xu <jeffxu@...gle.com>, Mickaël Salaün
 <mic@...ikod.net>
Cc: Al Viro <viro@...iv.linux.org.uk>, Christian Brauner
 <brauner@...nel.org>, Kees Cook <keescook@...omium.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Paul Moore <paul@...l-moore.com>, Theodore Ts'o <tytso@....edu>,
 Alejandro Colomar <alx.manpages@...il.com>, Aleksa Sarai
 <cyphar@...har.com>, Andrew Morton <akpm@...ux-foundation.org>,
 Andy Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>,
 Casey Schaufler <casey@...aufler-ca.com>,
 Christian Heimes <christian@...hon.org>, Dmitry Vyukov <dvyukov@...gle.com>,
 Eric Biggers <ebiggers@...nel.org>, Eric Chiang <ericchiang@...gle.com>,
 Fan Wu <wufan@...ux.microsoft.com>, Florian Weimer <fweimer@...hat.com>,
 Geert Uytterhoeven <geert@...ux-m68k.org>,
 James Morris <jamorris@...ux.microsoft.com>, Jan Kara <jack@...e.cz>,
 Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>,
 Jordan R Abrahams <ajordanr@...gle.com>,
 Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
 Luca Boccassi <bluca@...ian.org>, Luis Chamberlain <mcgrof@...nel.org>,
 "Madhavan T . Venkataraman" <madvenka@...ux.microsoft.com>,
 Matt Bobrowski <mattbobrowski@...gle.com>,
 Matthew Garrett <mjg59@...f.ucam.org>, Matthew Wilcox <willy@...radead.org>,
 Miklos Szeredi <mszeredi@...hat.com>, Mimi Zohar <zohar@...ux.ibm.com>,
 Nicolas Bouchinet <nicolas.bouchinet@....gouv.fr>,
 Scott Shell <scottsh@...rosoft.com>, Shuah Khan <shuah@...nel.org>,
 Stephen Rothwell <sfr@...b.auug.org.au>, Steve Grubb <sgrubb@...hat.com>,
 Thibaut Sautereau <thibaut.sautereau@....gouv.fr>,
 Vincent Strubel <vincent.strubel@....gouv.fr>,
 Xiaoming Ni <nixiaoming@...wei.com>, Yin Fengwei <fengwei.yin@...el.com>,
 kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-integrity@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)

On 17/07/2024 07:33, Jeff Xu wrote:
> Consider those cases: I think:
> a> relying purely on userspace for enforcement does't seem to be
> effective,  e.g. it is trivial  to call open(), then mmap() it into
> executable memory.

If there's a way to do this without running executable code that had to 
pass a previous execveat() check, then yeah, it's not effective (e.g. a 
Python interpreter that *doesn't* enforce execveat() is a trivial way to 
do it).

Once arbitrary code is running, all bets are off. So long as all 
arbitrary code is being checked itself, it's allowed to do things that 
would bypass later checks (and it's up to whoever audited it in the 
first place to prevent this by not giving it the special mark that 
allows it to pass the check).

> b> if both user space and kernel need to call AT_CHECK, the faccessat
> seems to be a better place for AT_CHECK, e.g. kernel can call
> do_faccessat(AT_CHECK) and userspace can call faccessat(). This will
> avoid complicating the execveat() code path.
> 
> What do you think ?
> 
> Thanks
> -Jeff