From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C4F5306487 for ; Mon, 1 Sep 2025 16:25:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756743923; cv=none; b=G6aAT8xAargBPBEaQ1LCbs8x5R385Gq5WOfZH+8+ejrA+az5rRNrMRjjbPGx1B2L3C0eH9old5WF9fBLRBxeGhHALMeFiSfq4rENz5Wf36Tei9+3rHQBhX5VHvdRYwfyNcym3Az9mlLPyqkg6Btm8VVwaewvMPzSG02/BiW/X1k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756743923; c=relaxed/simple; bh=Xy9c0RnED3HT39yD+fhi1E7AHRKldhfJxdRE7gKyi/E=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CfK7jk5tLE3wJ6CHwf5IJLvSjaixKrNHWAyepV+SAx2h+p9veL3kAH09iosy3XS/z7MgW90afOpXUmy8Nw5zvROGmhok5M2BJJ9WanfNCPGiUhvWBzKgIWOUJm7KAbyJZRt0wvDI6K69xWgC7TC2/urXdTOKpD1QPma2Ikciquo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z7IU2/Fs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z7IU2/Fs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1BFEAC4CEF4 for ; Mon, 1 Sep 2025 16:25:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756743923; bh=Xy9c0RnED3HT39yD+fhi1E7AHRKldhfJxdRE7gKyi/E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Z7IU2/FsWPS2YWB0kzeYM2ObtiwET9Kra0CYZYw06ild8oKNLCkxWc7Vfsm9bVuQe 4ZzPUt4sqB2bDQ+SI3eAssF/kmXIB0Y93UTATCsPHb5bGk1BvbNvXgMO3iYCBTXLLs 8c7e+7i1hw/nfIVNVge3CR/QjSNdpGWvLuaCuXYIbWk6PLSrrLq6JyYopyxuqgCZrN Zmkgq+utnmXu+vCfB1DRCRZ1kVm7edWVi9ifrqSx0PAq/TsjN6omcEtXW6BUWSBlAz vfW8gEZO7B/KKnMedjJbfDn/aXGDweWBmAuE1REQj04J8I9H9uv0be/+OS0n+iCF1Y 2JunIyl9GjxiQ== Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-333f901b2d2so40322011fa.2 for ; Mon, 01 Sep 2025 09:25:23 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUjKMURMJFY91Iv6dD1YtCf6W2E6dy/qnvsE9JyeX2lIiXQKZEOqOX1Hm//MgqqTF2xM8dUAWQLLMr4cm/fo8d/eW8gof4=@vger.kernel.org X-Gm-Message-State: AOJu0YzLCJsEMotYLcgwV8o3Zxrmhp0zIvm8cQO6eej+OlM9MPgscU3d 7dgG/DkEQrMrGoxJZuPYPY1ns7+cxOw04kTL+OLHmFO7hvf0fuC6ifIlnVv9eEwZ+Dhoo+egqPI MlVr8d5YeC02Sr2Wroko+02VlDl5Gp/J1Xsy1Pmja X-Google-Smtp-Source: AGHT+IHQaKnUNWLNFQYNtSQSa47g2pu7CpYY6T/b9pUgP8BH0aybd+qYJdHgPCMppjygHDMCLF/KHVs2OD16WVL33oA= X-Received: by 2002:a05:651c:1543:b0:336:e1c4:6c6f with SMTP id 38308e7fff4ca-336e1c47336mr14179671fa.19.1756743920925; Mon, 01 Sep 2025 09:25:20 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250822170800.2116980-1-mic@digikod.net> <20250826-skorpion-magma-141496988fdc@brauner> <20250826.aig5aiShunga@digikod.net> <2025-08-27-obscene-great-toy-diary-X1gVRV@cyphar.com> <54e27d05bae55749a975bc7cbe109b237b2b1323.camel@huaweicloud.com> In-Reply-To: <54e27d05bae55749a975bc7cbe109b237b2b1323.camel@huaweicloud.com> From: Andy Lutomirski Date: Mon, 1 Sep 2025 09:25:09 -0700 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXxyw6xiBo675X_GNr-mU7ryRcDYbQiEmCEhhXrRzSi1-YYVHnkbnMyWAA0 Message-ID: Subject: Re: [RFC PATCH v1 0/2] Add O_DENY_WRITE (complement AT_EXECVE_CHECK) To: Roberto Sassu Cc: Aleksa Sarai , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Christian Brauner , Al Viro , Kees Cook , Paul Moore , Serge Hallyn , Andy Lutomirski , Arnd Bergmann , Christian Heimes , Dmitry Vyukov , Elliott Hughes , Fan Wu , Florian Weimer , Jann Horn , Jeff Xu , Jonathan Corbet , Jordan R Abrahams , Lakshmi Ramasubramanian , Luca Boccassi , Matt Bobrowski , Miklos Szeredi , Mimi Zohar , Nicolas Bouchinet , Robert Waite , Roberto Sassu , Scott Shell , Steve Dower , Steve Grubb , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can you clarify this a bit for those of us who are not well-versed in exactly what "measurement" does? On Mon, Sep 1, 2025 at 2:42=E2=80=AFAM Roberto Sassu wrote: > > Now, in cases where you have IMA or something and you only permit signe= d > > binaries to execute, you could argue there is a different race here (an > > attacker creates a malicious script, runs it, and then replaces it with > > a valid script's contents and metadata after the fact to get > > AT_EXECVE_CHECK to permit the execution). However, I'm not sure that > > Uhm, let's consider measurement, I'm more familiar with. > > I think the race you wanted to express was that the attacker replaces > the good script, verified with AT_EXECVE_CHECK, with the bad script > after the IMA verification but before the interpreter reads it. > > Fortunately, IMA is able to cope with this situation, since this race > can happen for any file open, where of course a file can be not read- > locked. I assume you mean that this has nothing specifically to do with scripts, as IMA tries to protect ordinary (non-"execute" file access) as well. Am I right? > > If the attacker tries to concurrently open the script for write in this > race window, IMA will report this event (called violation) in the > measurement list, and during remote attestation it will be clear that > the interpreter did not read what was measured. > > We just need to run the violation check for the BPRM_CHECK hook too > (then, probably for us the O_DENY_WRITE flag or alternative solution > would not be needed, for measurement). This seems consistent with my interpretation above, but ... > > Please, let us know when you apply patches like 2a010c412853 ("fs: > don't block i_writecount during exec"). We had a discussion [1], but > probably I missed when it was decided to be applied (I saw now it was > in the same thread, but didn't get that at the time). We would have > needed to update our code accordingly. In the future, we will try to > clarify better our expectations from the VFS. ... I didn't follow this. Suppose there's some valid contents of /bin/sleep. I execute /bin/sleep 1m. While it's running, I modify /bin/sleep (by opening it for write, not by replacing it), and the kernel in question doesn't do ETXTBSY. Then the sleep process reads (and executes) the modified contents. Wouldn't a subsequent attestation fail? Why is ETXTBSY needed?