public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: "Guozihua (Scott)" <guozihua@huawei.com>,
	dmitry.kasatkin@gmail.com, Paul Moore <paul@paul-moore.com>,
	sds@tycho.nsa.gov, eparis@parisplace.org,
	Greg KH <gregkh@linuxfoundation.org>,
	sashal@kernel.org
Cc: selinux@vger.kernel.org,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	stable@vger.kernel.org
Subject: Re: [RFC] IMA LSM based rule race condition issue on 4.19 LTS
Date: Tue, 13 Dec 2022 10:30:08 -0500	[thread overview]
Message-ID: <efd4ce83299a10b02b1c04cc94934b8d51969e1c.camel@linux.ibm.com> (raw)
In-Reply-To: <389334fe-6e12-96b2-6ce9-9f0e8fcb85bf@huawei.com>

On Fri, 2022-12-09 at 15:00 +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.
> 
> The cause is that selinux_audit_rule_init() would set the rule (which is 
> a second level pointer) to NULL immediately after called. The relevant 
> codes are as shown:
> 
> security/selinux/ss/services.c:
> > int selinux_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule)
> > {
> >         struct selinux_state *state = &selinux_state;
> >         struct policydb *policydb = &state->ss->policydb;
> >         struct selinux_audit_rule *tmprule;
> >         struct role_datum *roledatum;
> >         struct type_datum *typedatum;
> >         struct user_datum *userdatum;
> >         struct selinux_audit_rule **rule = (struct selinux_audit_rule **)vrule;
> >         int rc = 0;
> > 
> >         *rule = NULL;
> *rule is set to NULL here, which means the rule on IMA side is also NULL.
> > 
> >         if (!state->initialized)
> >                 return -EOPNOTSUPP;
> ...
> > out:
> >         read_unlock(&state->ss->policy_rwlock);
> > 
> >         if (rc) {
> >                 selinux_audit_rule_free(tmprule);
> >                 tmprule = NULL;
> >         }
> > 
> >         *rule = tmprule;
> rule is updated at the end of the function.
> > 
> >         return rc;
> > }
> 
> security/integrity/ima/ima_policy.c:
> > static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode,
> >                             const struct cred *cred, u32 secid,
> >                             enum ima_hooks func, int mask)
> > {...
> > for (i = 0; i < MAX_LSM_RULES; i++) {
> >                 int rc = 0;
> >                 u32 osid;
> >                 int retried = 0;
> > 
> >                 if (!rule->lsm[i].rule)
> >                         continue;
> Setting rule to NULL would lead to LSM based rule matching being skipped.
> > retry:
> >                 switch (i) {
> 
> To solve this issue, there are multiple approaches we might take and I 
> would like some input from the community.
> 
> The first proposed solution would be to change 
> selinux_audit_rule_init(). Remove the set to NULL bit and update the 
> rule pointer with cmpxchg.
> 
> > diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> > index a9f2bc8443bd..aa74b04ccaf7 100644
> > --- a/security/selinux/ss/services.c
> > +++ b/security/selinux/ss/services.c
> > @@ -3297,10 +3297,9 @@ int selinux_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule)
> >         struct type_datum *typedatum;
> >         struct user_datum *userdatum;
> >         struct selinux_audit_rule **rule = (struct selinux_audit_rule **)vrule;
> > +       struct selinux_audit_rule *orig = rule;
> >         int rc = 0;
> >  
> > -       *rule = NULL;
> > -
> >         if (!state->initialized)
> >                 return -EOPNOTSUPP;
> >  
> > @@ -3382,7 +3381,8 @@ int selinux_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule)
> >                 tmprule = NULL;
> >         }
> >  
> > -       *rule = tmprule;
> > +       if (cmpxchg(rule, orig, tmprule) != orig)
> > +               selinux_audit_rule_free(tmprule);
> >  
> >         return rc;
> >  }
> 
> This solution would be an easy fix, but might influence other modules 
> calling selinux_audit_rule_init() directly or indirectly (on 4.19 LTS, 
> only auditfilter and IMA it seems). And it might be worth returning an 
> error code such as -EAGAIN.
> 
> Or, we can access rules via RCU, similar to what we do on 5.10. This 
> could means more code change and testing.

In the 4.19 kernel, IMA is doing a lazy LSM based policy rule update as
needed.  IMA waits for selinux_audit_rule_init() to complete and
shouldn't see NULL, unless there is an SELinux failure.  Before
"fixing" the problem, what exactly is the problem?

thanks,

Mimi


  parent reply	other threads:[~2022-12-13 15:30 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09  7:00 [RFC] IMA LSM based rule race condition issue on 4.19 LTS Guozihua (Scott)
2022-12-09  7:12 ` Greg KH
2022-12-09  7:53   ` Guozihua (Scott)
2022-12-09  8:46     ` Greg KH
2022-12-09  8:59       ` Guozihua (Scott)
2022-12-09  9:00         ` Greg KH
2022-12-09  9:11           ` Guozihua (Scott)
2022-12-09  9:22             ` Greg KH
2022-12-09  9:32               ` Guozihua (Scott)
2022-12-09  9:38                 ` Guozihua (Scott)
2022-12-09 10:27                   ` Greg KH
2022-12-12  2:39                     ` Guozihua (Scott)
2022-12-13 15:30 ` Mimi Zohar [this message]
2022-12-14  1:33   ` Guozihua (Scott)
2022-12-14 12:19     ` Mimi Zohar
2022-12-15  8:51       ` Guozihua (Scott)
2022-12-15 10:49         ` Mimi Zohar
2022-12-15 13:15           ` Guozihua (Scott)
2022-12-15 14:30             ` Mimi Zohar
2022-12-15 21:04               ` Paul Moore
2022-12-16  2:36                 ` Guozihua (Scott)
2022-12-16  3:04                   ` Paul Moore
2022-12-19  7:10                     ` Guozihua (Scott)
2022-12-19 13:11                       ` Mimi Zohar
2022-12-20  1:11                         ` Guozihua (Scott)
2022-12-21 10:51                           ` Guozihua (Scott)
2022-12-23  8:04                             ` Guozihua (Scott)
2022-12-24  3:41                               ` Guozihua (Scott)
2022-12-24  7:47                                 ` Guozihua (Scott)
2023-01-06  1:05                     ` Mimi Zohar

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=efd4ce83299a10b02b1c04cc94934b8d51969e1c.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=eparis@parisplace.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=guozihua@huawei.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=sashal@kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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