| Message ID | 20221227014729.4799-3-guozihua@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ima: Fix IMA mishandling of LSM based rule during | expand |
On Tue, Dec 27, 2022 at 09:47:29AM +0800, GUO Zihua wrote:
> [ Upstream commit c7423dbdbc9ecef7fff5239d144cad4b9887f4de ]
For obvious reasons we can not only take this patch (from 6.2-rc1) into
4.19.y as that would cause people who upgrade from 4.19.y to a newer
stable kernel to have a regression.
Please submit backports for all stable kernels if you wish to see this
in older ones to prevent problems like this from happening.
But also, why are you still on 4.19.y? What is wrong with 5.4.y at this
point in time? If we dropped support for 4.19.y in January, what would
that cause to happen for your systems?
thanks,
greg k-h
On Tue, 2022-12-27 at 08:37 +0100, Greg KH wrote: > On Tue, Dec 27, 2022 at 09:47:29AM +0800, GUO Zihua wrote: > > [ Upstream commit c7423dbdbc9ecef7fff5239d144cad4b9887f4de ] > > For obvious reasons we can not only take this patch (from 6.2-rc1) into > 4.19.y as that would cause people who upgrade from 4.19.y to a newer > stable kernel to have a regression. > > Please submit backports for all stable kernels if you wish to see this > in older ones to prevent problems like this from happening. Sasha has already queued the original commit and the dependencies for the 6.1, 6.0, and 5.15 stable kernels. Those kernels all had the call_lsm_notifier() to call_blocking_lsm_notifier() change. Prior to 5.3, the change to the blocking notifier would need to be backported as well. This version of the backport still needs to be reviewed. thanks, Mimi > > But also, why are you still on 4.19.y? What is wrong with 5.4.y at this > point in time? If we dropped support for 4.19.y in January, what would > that cause to happen for your systems? > > thanks, > > greg k-h >
Hi Greg and Mimi. Fall sick for a couple days. On 2022/12/27 19:56, Mimi Zohar wrote: > On Tue, 2022-12-27 at 08:37 +0100, Greg KH wrote: >> On Tue, Dec 27, 2022 at 09:47:29AM +0800, GUO Zihua wrote: >>> [ Upstream commit c7423dbdbc9ecef7fff5239d144cad4b9887f4de ] >> >> For obvious reasons we can not only take this patch (from 6.2-rc1) into >> 4.19.y as that would cause people who upgrade from 4.19.y to a newer >> stable kernel to have a regression. >> >> Please submit backports for all stable kernels if you wish to see this >> in older ones to prevent problems like this from happening. > > Sasha has already queued the original commit and the dependencies for > the 6.1, 6.0, and 5.15 stable kernels. Those kernels all had the > call_lsm_notifier() to call_blocking_lsm_notifier() change. Prior to > 5.3, the change to the blocking notifier would need to be backported as > well. This version of the backport still needs to be reviewed. Indeed the current solution needs further testing and review. One of the concern raised by Huaxin is a possible UAF caused by the call to free rule in update_rule. Will it be possible to backport also the change which turn call_lsm_notifier() into call_blocking_lsm_notifier()? > > thanks, > > Mimi > >> >> But also, why are you still on 4.19.y? What is wrong with 5.4.y at this >> point in time? If we dropped support for 4.19.y in January, what would >> that cause to happen for your systems? Well it's all about backward compatibility. We still got some products using the 4.19.y LTS kernel and we would still needs to provide support for this version of the kernel. If 4.19.y got EOL or EOS in January next year, our company surely would develop corresponding plans to handle that change. >> >> thanks, >> >> greg k-h >> >
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c index 1e0251e9510a..dd146a34a53a 100644 --- a/security/integrity/ima/ima_policy.c +++ b/security/integrity/ima/ima_policy.c @@ -378,6 +378,9 @@ static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode, enum ima_hooks func, int mask) { int i; + bool result = false; + struct ima_rule_entry *lsm_rule = rule; + bool rule_reinitialized = false; if ((rule->flags & IMA_FUNC) && (rule->func != func && func != POST_SETATTR)) @@ -416,35 +419,50 @@ static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode, int rc = 0; u32 osid; - if (!rule->lsm[i].rule) + if (!lsm_rule->lsm[i].rule) continue; +retry: switch (i) { case LSM_OBJ_USER: case LSM_OBJ_ROLE: case LSM_OBJ_TYPE: security_inode_getsecid(inode, &osid); rc = security_filter_rule_match(osid, - rule->lsm[i].type, + lsm_rule->lsm[i].type, Audit_equal, - rule->lsm[i].rule, + lsm_rule->lsm[i].rule, NULL); break; case LSM_SUBJ_USER: case LSM_SUBJ_ROLE: case LSM_SUBJ_TYPE: rc = security_filter_rule_match(secid, - rule->lsm[i].type, + lsm_rule->lsm[i].type, Audit_equal, - rule->lsm[i].rule, + lsm_rule->lsm[i].rule, NULL); default: break; } - if (!rc) - return false; + if (rc == -ESTALE && !rule_reinitialized) { + lsm_rule = ima_lsm_copy_rule(rule); + if (lsm_rule) { + rule_reinitialized = true; + goto retry; + } + } + if (!rc) { + result = false; + goto out; + } } - return true; + result = true; + +out: + if (rule_reinitialized) + ima_lsm_free_rule(lsm_rule); + return result; } /*
[ Upstream commit c7423dbdbc9ecef7fff5239d144cad4b9887f4de ] IMA relies on the blocking LSM policy notifier callback to update the LSM based IMA policy rules. When SELinux update its 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 to be measured by IMA. Fix it by re-initializing a temporary rule if -ESTALE is returned by ima_filter_rule_match(). The origin rule in the rule list would be updated by the LSM policy notifier callback. Fixes: b16942455193 ("ima: use the lsm policy update notifier") Signed-off-by: GUO Zihua <guozihua@huawei.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Cc: stable@vger.kernel.org # 4.19.y --- security/integrity/ima/ima_policy.c | 34 ++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 8 deletions(-)