[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrW=V9vst_ho2Q4sQUJ5uZECY5h7TnF==sG4JWq8PsWb8Q@mail.gmail.com>
Date: Wed, 27 Aug 2025 10:35:28 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Mickaël Salaün <mic@...ikod.net>
Cc: "Theodore Ts'o" <tytso@....edu>, Christian Brauner <brauner@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
Kees Cook <keescook@...omium.org>, Paul Moore <paul@...l-moore.com>,
Serge Hallyn <serge@...lyn.com>, Andy Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Christian Heimes <christian@...hon.org>, Dmitry Vyukov <dvyukov@...gle.com>,
Elliott Hughes <enh@...gle.com>, Fan Wu <wufan@...ux.microsoft.com>,
Florian Weimer <fweimer@...hat.com>, Jann Horn <jannh@...gle.com>, Jeff Xu <jeffxu@...gle.com>,
Jonathan Corbet <corbet@....net>, Jordan R Abrahams <ajordanr@...gle.com>,
Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>, Luca Boccassi <bluca@...ian.org>,
Matt Bobrowski <mattbobrowski@...gle.com>, Miklos Szeredi <mszeredi@...hat.com>,
Mimi Zohar <zohar@...ux.ibm.com>,
Nicolas Bouchinet <nicolas.bouchinet@....cyber.gouv.fr>, Robert Waite <rowait@...rosoft.com>,
Roberto Sassu <roberto.sassu@...wei.com>, Scott Shell <scottsh@...rosoft.com>,
Steve Dower <steve.dower@...hon.org>, Steve Grubb <sgrubb@...hat.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 v1 0/2] Add O_DENY_WRITE (complement AT_EXECVE_CHECK)
On Tue, Aug 26, 2025 at 10:47 AM Mickaël Salaün <mic@...ikod.net> wrote:
>
> On Tue, Aug 26, 2025 at 08:30:41AM -0400, Theodore Ts'o wrote:
> > Is there a single, unified design and requirements document that
> > describes the threat model, and what you are trying to achieve with
> > AT_EXECVE_CHECK and O_DENY_WRITE? I've been looking at the cover
> > letters for AT_EXECVE_CHECK and O_DENY_WRITE, and the documentation
> > that has landed for AT_EXECVE_CHECK and it really doesn't describe
> > what *are* the checks that AT_EXECVE_CHECK is trying to achieve:
> >
> > "The AT_EXECVE_CHECK execveat(2) flag, and the
> > SECBIT_EXEC_RESTRICT_FILE and SECBIT_EXEC_DENY_INTERACTIVE
> > securebits are intended for script interpreters and dynamic linkers
> > to enforce a consistent execution security policy handled by the
> > kernel."
>
> From the documentation:
>
> Passing the AT_EXECVE_CHECK flag to execveat(2) only performs a check
> on a regular file and returns 0 if execution of this file would be
> allowed, ignoring the file format and then the related interpreter
> dependencies (e.g. ELF libraries, script’s shebang).
>
> >
> > Um, what security policy?
>
> Whether the file is allowed to be executed. This includes file
> permission, mount point option, ACL, LSM policies...
This needs *waaaaay* more detail for any sort of useful evaluation.
Is an actual credible security policy rolling dice? Asking ChatGPT?
Looking at security labels? Does it care who can write to the file,
or who owns the file, or what the file's hash is, or what filesystem
it's on, or where it came from? Does it dynamically inspect the
contents? Is it controlled by an unprivileged process?
I can easily come up with security policies for which DENYWRITE is
completely useless. I can come up with convoluted and
not-really-credible policies where DENYWRITE is important, but I'm
honestly not sure that those policies are actually useful. I'm
honestly a bit concerned that AT_EXECVE_CHECK is fundamentally busted
because it should have been parametrized by *what format is expected*
-- it might be possible to bypass a policy by executing a perfectly
fine Python script using bash, for example.
I genuinely have not come up with a security policy that I believe
makes sense that needs AT_EXECVE_CHECK and DENYWRITE. I'm not saying
that such a policy does not exist -- I'm saying that I have not
thought of such a thing after a few minutes of thought and reading
these threads.
> > And then on top of it, why can't you do these checks by modifying the
> > script interpreters?
>
> The script interpreter requires modification to use AT_EXECVE_CHECK.
>
> There is no other way for user space to reliably check executability of
> files (taking into account all enforced security
> policies/configurations).
>
As mentioned above, even AT_EXECVE_CHECK does not obviously accomplish
this goal. If it were genuinely useful, I would much, much prefer a
totally different API: a *syscall* that takes, as input, a file
descriptor of something that an interpreter wants to execute and a
whole lot of context as to what that interpreter wants to do with it.
And I admit I'm *still* not convinced.
Seriously, consider all the unending recent attacks on LLMs an
inspiration. The implications of viewing an image, downscaling the
image, possibly interpreting the image as something containing text,
possibly following instructions in a given language contained in the
image, etc are all wildly different. A mechanism for asking for
general permission to "consume this image" is COMPLETELY MISSING THE
POINT. (Never mind that the current crop of LLMs seem entirely
incapable of constraining their own use of some piece of input, but
that's a different issue and is besides the point here.)
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.
