From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Amir Goldstein <amir73il@gmail.com>,
Stefan Berger <stefanb@linux.ibm.com>
Cc: 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
Subject: Re: [RFC PATCH v2 0/2] ima: Fix detection of read/write violations on stacked filesystems
Date: Thu, 25 Apr 2024 13:30:04 +0200 [thread overview]
Message-ID: <a8da6b9f57095be494b8c38ca46e2a102b8eafac.camel@huaweicloud.com> (raw)
In-Reply-To: <CAOQ4uxgvHjU-n56ryOp5yWQF=yKz0Cfo0ZieypWJhqsBV4g-2w@mail.gmail.com>
On Tue, 2024-04-23 at 09:02 +0300, Amir Goldstein wrote:
> On Mon, Apr 22, 2024 at 6:07 PM Stefan Berger <stefanb@linux.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.
next prev parent reply other threads:[~2024-04-25 11:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 15:06 [RFC PATCH v2 0/2] ima: Fix detection of read/write violations on stacked filesystems Stefan Berger
2024-04-22 15:06 ` [RFC PATCH v2 1/2] ovl: Define D_REAL_FILEDATA for d_real to return dentry with data Stefan Berger
2024-04-23 5:54 ` Amir Goldstein
2024-04-22 15:06 ` [RFC PATCH v2 2/2] ima: Fix detection of read/write violations on stacked filesystems Stefan Berger
2024-04-22 16:15 ` Roberto Sassu
2024-04-23 6:02 ` [RFC PATCH v2 0/2] " Amir Goldstein
2024-04-23 10:53 ` Stefan Berger
2024-04-23 13:20 ` Roberto Sassu
2024-04-23 14:30 ` Amir Goldstein
2024-04-26 9:51 ` Christian Brauner
2024-04-25 11:30 ` Roberto Sassu [this message]
2024-04-25 12:37 ` Amir Goldstein
2024-04-26 7:34 ` Roberto Sassu
2024-04-27 9:03 ` Amir Goldstein
2024-05-06 12:34 ` Roberto Sassu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a8da6b9f57095be494b8c38ca46e2a102b8eafac.camel@huaweicloud.com \
--to=roberto.sassu@huaweicloud.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=roberto.sassu@huawei.com \
--cc=stefanb@linux.ibm.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.