linux-kernel - Re: [RFC PATCH v2 0/2] ima: Fix detection of read/write violations on stacked filesystems

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAOQ4uxgvHjU-n56ryOp5yWQF=yKz0Cfo0ZieypWJhqsBV4g-2w@mail.gmail.com>
Date: Tue, 23 Apr 2024 09:02:58 +0300
From: Amir Goldstein <amir73il@...il.com>
To: Stefan Berger <stefanb@...ux.ibm.com>
Cc: linux-integrity@...r.kernel.org, linux-unionfs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, zohar@...ux.ibm.com, roberto.sassu@...wei.com, 
	miklos@...redi.hu, brauner@...nel.org
Subject: Re: [RFC PATCH v2 0/2] ima: Fix detection of read/write violations on
 stacked filesystems

On Mon, Apr 22, 2024 at 6:07 PM Stefan Berger <stefanb@...ux.ibm.com> wrote:
>
> This series fixes the detection of read/write violations on stacked
> filesystems. To be able to access the relevant dentries necessary to
> detect files opened for writing on a stacked filesystem a new d_real_type
> D_REAL_FILEDATA is introduced that allows callers to access all relevant
> files involved in a stacked filesystem while traversing the layers.
>

Stefan,

Both Miklos and myself objected to this solution:
https://lore.kernel.org/linux-unionfs/CAJfpeguctirEYECoigcAsJwpGPCX2NyfMZ8H8GHGW-0UyKfjgg@mail.gmail.com/

Not sure what you are hoping to achieve from re-posting the same solution.

I stopped counting how many times I already argued that *all* IMA/EVM
assertions,
including rw-ro violations should be enforced only on the real inode.
I know this does not work - so you should find out why it does not work and fix
the problem.

Enforcing IMA/EVM on the overlayfs inode layer is just the wrong way IMO.
Not once have I heard an argument from IMA/EVM developers why it is really
needed to enforce IMA/EVM on the overlayfs inode layer and not on the
real inode.
I am sorry that we are failing to communicate on this matter, but I am not
sure how else I can help.

Thanks,
Amir.