From: Stefan Berger <stefanb@linux.ibm.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
zohar@linux.ibm.com, roberto.sassu@huawei.com, miklos@szeredi.hu
Subject: Re: [PATCH 4/5] evm: Use the real inode's metadata to calculate metadata hash
Date: Fri, 2 Feb 2024 11:30:24 -0500 [thread overview]
Message-ID: <d00e0b2f-7cd8-48d9-aac9-2463af3e3c24@linux.ibm.com> (raw)
In-Reply-To: <CAOQ4uxhkyh19rMXnZ+Ou-Z0DgraBJAvL53K_PK9zRUB2O-Lsqw@mail.gmail.com>
On 2/2/24 11:17, Amir Goldstein wrote:
>> The odd thing is my updated test case '2' seems to indicate that
>> everything already works as expected with CONFIG_OVERLAY_FS_METACOPY=y.
>> After causing copy-up of metadata changes to the file content on the
>> lower layer still cause permission error to file execution on the
>> overlay layer and after restoring the file content on the lower the file
>> on the overlay again runs as expected. The file content change + copy-up
>> of file content also has completely decoupled the lower file from the
>> file on the overlay and changes to the file on the lower cause no more
>> file execution rejections on the overlay.
>>
>
> Sorry, you lost me.
> The combination of IMA+EVM+OVL must be too complicated to
> explain in plain language without an explicit test spelled out...
>
> When you write "The file content change + copy-up of file content also
> has completely decoupled the lower file from the file on the overlay",
> what do you mean by "copy up of the file content"?
> Why was the file content copied up?
The file was copied up by appending a byte to the file on the 'overlay'.
> I was asking about use case that only metadata was copied up but
> lower file content, which is still the content of the ovl file was changed
> underneath ovl - this case does not cause data content to be copied up.
>
> I don't think we understand each other.
One of the test cases I also have is appending a byte to the file on the
'lower'. At this point in the test one can detect whether
CONFIG_OVERLAY_FS_METACOPY is enabled by checking the sha1 of the files
on the lower and overlay layers and comparing their hashes. If they are
equal then CONFIG_OVERLAY_FS_METACOPY is enabled since previously in the
test file metadata on the overlay layer was already changed, which in
the CONFIG_OVERLAY_FS_METACOPY=y case only caused a copy-up of metadata.
So, when trying to execute the file on the overlay layer the file cannot
be executed due to the file content change on the lower layer (IMA
should be the one detecting this, need to check) still 'shining
through'. After restoring the file content on the lower layer the file
again executes on the 'overlay' layer - as expected.
Stefan
>
> Thanks,
> Amir.
next prev parent reply other threads:[~2024-02-02 16:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 21:46 [PATCH 0/5] evm: Support signatures on stacked filesystem Stefan Berger
2024-01-30 21:46 ` [PATCH 1/5] security: allow finer granularity in permitting copy-up of security xattrs Stefan Berger
2024-01-31 13:25 ` Amir Goldstein
2024-01-31 14:25 ` Christian Brauner
2024-01-31 14:56 ` Stefan Berger
2024-02-01 13:35 ` Christian Brauner
2024-02-01 14:18 ` Amir Goldstein
2024-02-02 11:58 ` Christian Brauner
2024-02-01 15:41 ` Stefan Berger
2024-01-31 16:47 ` kernel test robot
2024-01-31 19:06 ` kernel test robot
2024-01-30 21:46 ` [PATCH 2/5] evm: Implement per signature type decision in security_inode_copy_up_xattr Stefan Berger
2024-01-31 13:28 ` Amir Goldstein
2024-01-30 21:46 ` [PATCH 3/5] ima: Reset EVM status upon detecting changes to overlay backing file Stefan Berger
2024-01-31 13:56 ` Amir Goldstein
2024-01-31 14:46 ` Stefan Berger
2024-01-30 21:46 ` [PATCH 4/5] evm: Use the real inode's metadata to calculate metadata hash Stefan Berger
2024-01-31 2:10 ` Stefan Berger
2024-01-31 13:16 ` Amir Goldstein
2024-01-31 14:40 ` Stefan Berger
2024-01-31 15:54 ` Amir Goldstein
2024-01-31 17:23 ` Amir Goldstein
2024-01-31 17:46 ` Stefan Berger
2024-02-01 12:10 ` Amir Goldstein
2024-02-01 13:36 ` Stefan Berger
2024-02-01 14:11 ` Amir Goldstein
2024-02-01 20:35 ` Stefan Berger
2024-02-02 9:24 ` Amir Goldstein
2024-02-02 14:59 ` Stefan Berger
2024-02-02 15:51 ` Amir Goldstein
2024-02-02 16:06 ` Stefan Berger
2024-02-02 16:17 ` Amir Goldstein
2024-02-02 16:30 ` Stefan Berger [this message]
2024-01-31 17:25 ` Stefan Berger
2024-01-30 21:46 ` [PATCH 5/5] evm: Enforce signatures on unsupported filesystem for EVM_INIT_X509 Stefan Berger
2024-01-31 14:06 ` Amir Goldstein
2024-02-01 17:53 ` Mimi Zohar
2024-01-31 13:18 ` [PATCH 0/5] evm: Support signatures on stacked filesystem Amir Goldstein
2024-01-31 14:52 ` Stefan Berger
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=d00e0b2f-7cd8-48d9-aac9-2463af3e3c24@linux.ibm.com \
--to=stefanb@linux.ibm.com \
--cc=amir73il@gmail.com \
--cc=jmorris@namei.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).