Received-SPF: pass (google.com: domain of linux-kernel+bounces-50137-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <d00e0b2f-7cd8-48d9-aac9-2463af3e3c24@linux.ibm.com>
Date: Fri, 2 Feb 2024 11:30:24 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/5] evm: Use the real inode's metadata to calculate
 metadata hash
Content-Language: en-US
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
References: <20240130214620.3155380-1-stefanb@linux.ibm.com>
 <38230b4c-54ae-45ed-a6fb-34e63501e5b1@linux.ibm.com>
 <CAOQ4uxiYARZBSgzb4_W-RKvB1XLSF3GUBqeLw2kH+eVeZ_8ARQ@mail.gmail.com>
 <c018b014-9ba8-4395-86dc-b61346ab20a8@linux.ibm.com>
 <CAOQ4uxi6Te8izWpXROthknRaXrVA9jho5nbc+mkuQDrcTLY44Q@mail.gmail.com>
 <CAOQ4uxigdNeE+2nfr4VxS9piQf5hez=ryT0a-jzW+tW0BT-zuw@mail.gmail.com>
 <492ea12a-d79d-47da-9bbe-a7f33051bd3f@linux.ibm.com>
 <CAOQ4uxgiO1RbsmqOu4F4Foy-MBPecnEXO7BvgDGz-Lzb1Eysog@mail.gmail.com>
 <4c584bfb-d282-4584-bb20-18c26b1033c0@linux.ibm.com>
 <CAOQ4uxjftr7GGx6tuW_yB_MTaVB57m6p_d=UHhN3Z23YVXY0QQ@mail.gmail.com>
 <11abffea-15c5-4d13-9d0f-edbc54b09bf3@linux.ibm.com>
 <CAOQ4uxjZ6p9+H54G0LNTUnU56WRaoLtWOUj2nOaKJ4JvBGqLVg@mail.gmail.com>
 <427ce381-73fa-48f9-8e18-77e23813b918@linux.ibm.com>
 <CAOQ4uxggqa7j0NS1MN3KSvF_qG1FMVmFxacEYSTx+LuvuosJ5g@mail.gmail.com>
 <4ce0e20d-ed14-490d-9446-a6cfbd532bca@linux.ibm.com>
 <CAOQ4uxhkyh19rMXnZ+Ou-Z0DgraBJAvL53K_PK9zRUB2O-Lsqw@mail.gmail.com>
From: Stefan Berger <stefanb@linux.ibm.com>
In-Reply-To: <CAOQ4uxhkyh19rMXnZ+Ou-Z0DgraBJAvL53K_PK9zRUB2O-Lsqw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


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.