Received-SPF: pass (google.com: domain of linux-kernel+bounces-27682-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <5060b314-dc45-48c4-8c21-157219e4b6ee@schaufler-ca.com>
Date: Tue, 16 Jan 2024 10:18:52 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 13/25] security: Introduce file_release hook
Content-Language: en-US
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Roberto Sassu <roberto.sassu@huaweicloud.com>, brauner@kernel.org,
 chuck.lever@oracle.com, jlayton@kernel.org, neilb@suse.de, kolga@netapp.com,
 Dai.Ngo@oracle.com, tom@talpey.com, paul@paul-moore.com, jmorris@namei.org,
 serge@hallyn.com, zohar@linux.ibm.com, dmitry.kasatkin@gmail.com,
 eric.snowberg@oracle.com, dhowells@redhat.com, jarkko@kernel.org,
 stephen.smalley.work@gmail.com, eparis@parisplace.org, shuah@kernel.org,
 mic@digikod.net, linux-kernel@vger.kernel.org,
 linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
 linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org,
 keyrings@vger.kernel.org, selinux@vger.kernel.org,
 linux-kselftest@vger.kernel.org, Roberto Sassu <roberto.sassu@huawei.com>,
 Casey Schaufler <casey@schaufler-ca.com>
References: <20240115181809.885385-1-roberto.sassu@huaweicloud.com>
 <20240115181809.885385-14-roberto.sassu@huaweicloud.com>
 <20240115191508.GG1674809@ZenIV>
 <3b440f064a1ae04d69f7e85f4077f8406c0eac67.camel@huaweicloud.com>
 <00b7ff22-f213-471a-a604-658a9af80d59@schaufler-ca.com>
 <20240116173317.GL1674809@ZenIV>
From: Casey Schaufler <casey@schaufler-ca.com>
In-Reply-To: <20240116173317.GL1674809@ZenIV>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 1/16/2024 9:33 AM, Al Viro wrote:
> On Tue, Jan 16, 2024 at 08:51:11AM -0800, Casey Schaufler wrote:
>> On 1/16/2024 12:47 AM, Roberto Sassu wrote:
>>> On Mon, 2024-01-15 at 19:15 +0000, Al Viro wrote:
>>>> On Mon, Jan 15, 2024 at 07:17:57PM +0100, Roberto Sassu wrote:
>>>>> From: Roberto Sassu <roberto.sassu@huawei.com>
>>>>>
>>>>> In preparation for moving IMA and EVM to the LSM infrastructure, introduce
>>>>> the file_release hook.
>>>>>
>>>>> IMA calculates at file close the new digest of the file content and writes
>>>>> it to security.ima, so that appraisal at next file access succeeds.
>>>>>
>>>>> An LSM could implement an exclusive access scheme for files, only allowing
>>>>> access to files that have no references.
>>>> Elaborate that last part, please.
>>> Apologies, I didn't understand that either. Casey?
>> Just a hypothetical notion that if an LSM wanted to implement an
>> exclusive access scheme it might find the proposed hook helpful.
>> I don't have any plan to create such a scheme, nor do I think that
>> a file_release hook would be the only thing you'd need.
> Exclusive access to what?  "No more than one opened file with this
> inode at a time"?  It won't serialize IO operations, obviously...
> Details, please.

Once a file is opened it can't be opened again until it is closed.
That's the simple description, which ignores all sorts of cases.
I wouldn't want my system to behave that way, but I have heard
arguments that multiple concurrent opens can be a security issue.
In the context of my review of the code in question I included
the comment solely for the purpose of acknowledging the potential
for additional uses of the proposed hook. It's entirely possible
someone (not me!) would use the hook in this or some other "clever"
way.