Received-SPF: pass (google.com: domain of linux-kernel+bounces-158532-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240422150651.2908169-1-stefanb@linux.ibm.com>
 <CAOQ4uxgvHjU-n56ryOp5yWQF=yKz0Cfo0ZieypWJhqsBV4g-2w@mail.gmail.com> <a8da6b9f57095be494b8c38ca46e2a102b8eafac.camel@huaweicloud.com>
In-Reply-To: <a8da6b9f57095be494b8c38ca46e2a102b8eafac.camel@huaweicloud.com>
From: Amir Goldstein <amir73il@gmail.com>
Date: Thu, 25 Apr 2024 15:37:30 +0300
Message-ID: <CAOQ4uxjODtbaWPHS3bQvnEKuYAWTJa6kqsXCSzcsF1hJdThcsw@mail.gmail.com>
Subject: Re: [RFC PATCH v2 0/2] ima: Fix detection of read/write violations on
 stacked filesystems
To: Roberto Sassu <roberto.sassu@huaweicloud.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>, linux-integrity@vger.kernel.org, 
	linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org, 
	zohar@linux.ibm.com, roberto.sassu@huawei.com, miklos@szeredi.hu, 
	brauner@kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 25, 2024 at 2:30=E2=80=AFPM Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
>
> On Tue, 2024-04-23 at 09:02 +0300, Amir Goldstein wrote:
> > On Mon, Apr 22, 2024 at 6:07=E2=80=AFPM Stefan Berger <stefanb@linux.ib=
m.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 relev=
ant
> > > 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/CAJfpeguctirEYECoigcAsJwpGPCX2Nyf=
MZ8H8GHGW-0UyKfjgg@mail.gmail.com/
> >
> > Not sure what you are hoping to achieve from re-posting the same soluti=
on.
> >
> > 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 IM=
O.
> > Not once have I heard an argument from IMA/EVM developers why it is rea=
lly
> > 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=3Da,upperdir=3Db,workdir=3Dc,metacopy=3Don =
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=3Doverlay fowner=3D3000" > /sys/kernel/security/im=
a/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.
>

ok, it is simple to write an ima policy that is not respected by overlayfs.

My question is: under what circumstances is a policy like the above
useful in the real world?

Correct me if I am wrong, but AFAIK, the purpose of IMA/EVM is to
mitigate attack vectors of tampering with files offline or after the
file's data/metadata were measured. Is that a correct description?

AFAIK, IMA/EVM policy is system-wide and not namespace aware
so the policy has to be set on the container's host and not inside
containers. Is that correct?

If those statements are true then please try to explain to me what is
the thread model for tampering with overlayfs files, without tampering
with the real upper and/or lower files.

My thesis is that if an IMA/EVM policy is good enough to prevent
tampering with the real lower/upper files, then no extra measures
are needed to protect the virtual overlayfs files against tampering.

Is my thesis flawed?
I'm pretty sure that it is, but I never got a satisfying answer why.

Thanks,
Amir.