[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250827.Fuo1Iel1pa7i@digikod.net>
Date: Wed, 27 Aug 2025 21:07:35 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Andy Lutomirski <luto@...nel.org>
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>, 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 Wed, Aug 27, 2025 at 10:35:28AM -0700, Andy Lutomirski wrote:
> 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?
AT_EXECVE_CHECK only does the same checks as done by other execveat(2)
calls, but without actually executing the file/fd.
>
> 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.
There have been a lot of bikesheding for the AT_EXECVE_CHECK patch
series, and a lot of discussions too (you where part of them). We ended
up with this design, which is simple and follows the kernel semantic
(requested by Linus).
>
> 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.
A simple use case is for systems that wants to enforce a
write-xor-execute policy e.g., thanks to mount point options.
>
>
> > > 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.
As mentioned above, AT_EXECVE_CHECK follows the kernel semantic. Nothing
fancy.
>
> 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.)
You're asking about what should we consider executable. This is a good
question, but AT_EXECVE_CHECK is there to answer another question: would
the kernel execute it or not?
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.
