Received-SPF: pass (google.com: domain of linux-nfs+bounces-1133-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <00b7ff22-f213-471a-a604-658a9af80d59@schaufler-ca.com>
Date: Tue, 16 Jan 2024 08:51:11 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 13/25] security: Introduce file_release hook
To: Roberto Sassu <roberto.sassu@huaweicloud.com>,
 Al Viro <viro@zeniv.linux.org.uk>
Cc: 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>
Content-Language: en-US
From: Casey Schaufler <casey@schaufler-ca.com>
In-Reply-To: <3b440f064a1ae04d69f7e85f4077f8406c0eac67.camel@huaweicloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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.

>
> Thanks
>
> Roberto
>