[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lhuikibbv0g.fsf@oldenburg.str.redhat.com>
Date: Mon, 25 Aug 2025 11:39:11 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Mickaël Salaün <mic@...ikod.net>
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
* 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?
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.
Thanks,
Florian
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.
