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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <a8da6b9f57095be494b8c38ca46e2a102b8eafac.camel@huaweicloud.com>
Date: Thu, 25 Apr 2024 13:30:04 +0200
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Amir Goldstein <amir73il@...il.com>, 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 Tue, 2024-04-23 at 09:02 +0300, Amir Goldstein wrote:
> 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.

Ok, I try to provide an example regarding this, and we see if it makes
sense.

# echo test > test-file
# chown 2000 d/test-file
# ls -l a/test-file
-rw-r--r--. 1 2000 root 25 Apr 25 10:50 a/test-file

Initially there is a file in the lower layer with UID 2000.


# mount -t overlay -olowerdir=a,upperdir=b,workdir=c,metacopy=on overlay d
# chown 3000 d/test-file
# ls -l d/test-file
-rw-r--r--. 1 3000 root 25 Apr 25 10:50 d/test-file
# ls -l a/test-file
-rw-r--r--. 1 2000 root 25 Apr 25 10:50 a/test-file
# ls -l b/test-file
-rw-r--r--. 1 3000 root 25 Apr 25 10:50 b/test-file

If I have a policy like this:

# echo "measure fsname=overlay fowner=3000" > /sys/kernel/security/ima/policy

there won't be any match on the real file which still has UID 2000. But
what is observable by the processes through overlayfs is UID 3000.

Roberto

> I am sorry that we are failing to communicate on this matter, but I am not
> sure how else I can help.
> 
> Thanks,
> Amir.