Re: [RFC] IMA LSM based rule race condition issue on 4.19 LTS

Guozihua (Scott)
2022-12-12T02:39:30Z

On 2022/12/9 18:27, Greg KH wrote:
> On Fri, Dec 09, 2022 at 05:38:00PM +0800, Guozihua (Scott) wrote:
>> On 2022/12/9 17:32, Guozihua (Scott) wrote:
>>> On 2022/12/9 17:22, Greg KH wrote:
>>>> On Fri, Dec 09, 2022 at 05:11:40PM +0800, Guozihua (Scott) wrote:
>>>>> On 2022/12/9 17:00, Greg KH wrote:
>>>>>> On Fri, Dec 09, 2022 at 04:59:17PM +0800, Guozihua (Scott) wrote:
>>>>>>> On 2022/12/9 16:46, Greg KH wrote:
>>>>>>>> On Fri, Dec 09, 2022 at 03:53:25PM +0800, Guozihua (Scott) wrote:
>>>>>>>>> On 2022/12/9 15:12, Greg KH wrote:
>>>>>>>>>> On Fri, Dec 09, 2022 at 03:00:35PM +0800, Guozihua (Scott) wrote:
>>>>>>>>>>> Hi community.
>>>>>>>>>>>
>>>>>>>>>>> Previously our team reported a race condition in IMA relates to LSM based
>>>>>>>>>>> rules which would case IMA to match files that should be filtered out under
>>>>>>>>>>> normal condition. The issue was originally analyzed and fixed on mainstream.
>>>>>>>>>>> The patch and the discussion could be found here:
>>>>>>>>>>> https://lore.kernel.org/all/20220921125804.59490-1-guozihua@huawei.com/
>>>>>>>>>>>
>>>>>>>>>>> After that, we did a regression test on 4.19 LTS and the same issue arises.
>>>>>>>>>>> Further analysis reveled that the issue is from a completely different
>>>>>>>>>>> cause.
>>>>>>>>>>
>>>>>>>>>> What commit in the tree fixed this in newer kernels? Why can't we just
>>>>>>>>>> backport that one to 4.19.y as well?
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>>
>>>>>>>>>> greg k-h
>>>>>>>>>
>>>>>>>>> Hi Greg,
>>>>>>>>>
>>>>>>>>> The fix for mainline is now on linux-next, commit d57378d3aa4d ("ima:
>>>>>>>>> Simplify ima_lsm_copy_rule") and c7423dbdbc9ece ("ima: Handle -ESTALE
>>>>>>>>> returned by ima_filter_rule_match()"). However, these patches cannot be
>>>>>>>>> picked directly into 4.19.y due to code difference.
>>>>>>>>
>>>>>>>> Ok, so it's much more than just 4.19 that's an issue here. And are
>>>>>>>> those commits tagged for stable inclusion?
>>>>>>>
>>>>>>> Not actually, not on the commit itself.
>>>>>>
>>>>>> That's not good. When they hit Linus's tree, please submit backports to
>>>>>> the stable mailing list so that they can be picked up.
>>>>> Thing is these commits cannot be simply backported to 4.19.y. Preceding
>>>>> patches are missing. How do we do backporting in this situation? Do we
>>>>> first backport the preceding patches? Or maybe we develop another
>>>>> solution for 4.19.y?
>>>>
>>>> First they need to go to newer kernel trees, and then worry about 4.19.
>>>> We never want anyone to upgrade to a newer kernel and have a regression.
>>>>
>>>> Also, we can't do anything until they hit Linus's tree, as per the
>>>> stable kernel rules.
>>> Alright. We'll wait for these patches to be in Linus' tree. But should
>>> we stick to a backport from mainstream or we form a different solution
>>> for LTS?
>
> We always want to have a normal backport of what is in Linus's tree if
> at all possible. Whenever we diverge from that, we almost always get it
> wrong and have to fix it up again later.
>
>> BTW, I have a look into it and if we are backporting mainstream's
>> solution, we would also needs to backport b16942455193 ("ima: use the
>> lsm policy update notifier")
>
> That's fine, please just send a patch series to the stable list when
> needed.
>
> thanks,
>
> greg k-h

Thanks Greg.

Any thought from Mimi?

--
Best
GUO Zihua