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

[Greg KH <gregkh@linuxfoundation.org>]

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