linux-kernel - Re: [PATCH v9 13/25] security: Introduce file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 16 Jan 2024 10:18:52 -0800
From: Casey Schaufler <casey@...aufler-ca.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Roberto Sassu <roberto.sassu@...weicloud.com>, brauner@...nel.org,
 chuck.lever@...cle.com, jlayton@...nel.org, neilb@...e.de, kolga@...app.com,
 Dai.Ngo@...cle.com, tom@...pey.com, paul@...l-moore.com, jmorris@...ei.org,
 serge@...lyn.com, zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
 eric.snowberg@...cle.com, dhowells@...hat.com, jarkko@...nel.org,
 stephen.smalley.work@...il.com, eparis@...isplace.org, shuah@...nel.org,
 mic@...ikod.net, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
 linux-security-module@...r.kernel.org, linux-integrity@...r.kernel.org,
 keyrings@...r.kernel.org, selinux@...r.kernel.org,
 linux-kselftest@...r.kernel.org, Roberto Sassu <roberto.sassu@...wei.com>,
 Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v9 13/25] security: Introduce file_release hook

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@...wei.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.