From: "Guozihua (Scott)" <guozihua@huawei.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
<linux-integrity@vger.kernel.org>, <dmitry.kasatkin@gmail.com>,
<paul@paul-moore.com>
Subject: Re: [PATCH] ima: Handle -ESTALE returned by ima_filter_rule_match()
Date: Fri, 19 Aug 2022 09:50:18 +0800 [thread overview]
Message-ID: <998ca87c-8eef-8d50-e1ee-da53ef8f0046@huawei.com> (raw)
In-Reply-To: <b383f302284dfa31408e2796a9cae60eefd45004.camel@linux.ibm.com>
On 2022/8/18 21:43, Mimi Zohar wrote:
> Hi Scott,
>
> On Thu, 2022-08-18 at 10:05 +0800, GUO Zihua wrote:
>> IMA relies on lsm policy update notifier to be notified when it should
>> update it's lsm rules.
>
> ^IMA relies on the blocking LSM policy notifier callback to update the
> LSM based IMA policy rules.
I'll fix this in the next version.
>
>> When SELinux update it's policies, ima would be notified and starts
>> updating all its lsm rules one-by-one. During this time, -ESTALE would
>> be returned by ima_filter_rule_match() if it is called with a lsm rule
>> that has not yet been updated. In ima_match_rules(), -ESTALE is not
>> handled, and the lsm rule is considered a match, causing extra files
>> be measured by IMA.
>>
>> Fix it by retrying for at most three times if -ESTALE is returned by
>> ima_filter_rule_match().
>
> With the lazy LSM policy update, retrying only once was needed. With
> the blocking LSM notifier callback, why is three times needed? Is this
> really a function of how long it takes IMA to walk and update ALL the
> LSM based IMA policy rules? Would having SELinux wait for the -ESTALE
> to change do anything?
With lazy policy update, policy update is triggered and would be
finished before retrying. However, with a notifier callback, the update
runs in a different process which might introduce extra latency.
Technically if one rule has been updated, any following rules would have
been updated at the time they are read as well, thus the retry should
happen on the first rule affected by SELinux policy update only.
Retrying for three times here would leave some time for the notifier to
finish it's job on updating the rules.
>>
>> Fixes: b16942455193 ("ima: use the lsm policy update notifier")
>> Signed-off-by: GUO Zihua <guozihua@huawei.com>
>
> thanks,
>
> Mimi
>
> .
--
Best
GUO Zihua
next prev parent reply other threads:[~2022-08-19 1:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 2:05 [PATCH] ima: Handle -ESTALE returned by ima_filter_rule_match() GUO Zihua
2022-08-18 13:43 ` Mimi Zohar
2022-08-19 1:50 ` Guozihua (Scott) [this message]
2022-08-22 14:41 ` Mimi Zohar
2022-08-23 8:12 ` Guozihua (Scott)
2022-08-23 13:21 ` Mimi Zohar
2022-08-23 13:28 ` Guozihua (Scott)
2022-08-24 1:26 ` Mimi Zohar
2022-08-24 1:56 ` Guozihua (Scott)
2022-08-25 13:02 ` Mimi Zohar
2022-08-27 9:57 ` Guozihua (Scott)
2022-08-30 1:20 ` Mimi Zohar
2022-08-30 8:41 ` Guozihua (Scott)
2022-08-30 12:03 ` Mimi Zohar
2022-08-30 12:13 ` Guozihua (Scott)
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=998ca87c-8eef-8d50-e1ee-da53ef8f0046@huawei.com \
--to=guozihua@huawei.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=linux-integrity@vger.kernel.org \
--cc=paul@paul-moore.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