[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250826.Lie3ye8to7yo@digikod.net>
Date: Tue, 26 Aug 2025 14:35:08 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Florian Weimer <fweimer@...hat.com>
Cc: Andy Lutomirski <luto@...capital.net>, Jann Horn <jannh@...gle.com>,
Al Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>,
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>, 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, Jeff Xu <jeffxu@...omium.org>
Subject: Re: [RFC PATCH v1 1/2] fs: Add O_DENY_WRITE
On Mon, Aug 25, 2025 at 11:39:11AM +0200, Florian Weimer wrote:
> * Mickaël Salaün:
>
> > The order of checks would be:
> > 1. open script with O_DENY_WRITE
> > 2. check executability with AT_EXECVE_CHECK
> > 3. read the content and interpret it
> >
> > The deny-write feature was to guarantee that there is no race condition
> > between step 2 and 3. All these checks are supposed to be done by a
> > trusted interpreter (which is allowed to be executed). The
> > AT_EXECVE_CHECK call enables the caller to know if the kernel (and
> > associated security policies) allowed the *current* content of the file
> > to be executed. Whatever happen before or after that (wrt.
> > O_DENY_WRITE) should be covered by the security policy.
>
> Why isn't it an improper system configuration if the script file is
> writable?
It is, except if the system only wants to track executions (e.g. record
checksum of scripts) without restricting file modifications.
>
> In the past, the argument was that making a file (writable and)
> executable was an auditable even, and that provided enough coverage for
> those people who are interested in this.
Yes, but in this case there is a race condition that this patch tried to
fix.
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.
