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.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ