| Message ID | 20180926203446.2004-3-casey.schaufler@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | LSM: Support ptrace sidechannel access checks | expand |
On Wed, Sep 26, 2018 at 10:35 PM Casey Schaufler <casey.schaufler@intel.com> wrote: > A ptrace access check with mode PTRACE_MODE_SCHED gets called > from process switching code. This precludes the use of audit, > as the locking is incompatible. Don't do audit in the PTRACE_MODE_SCHED > case. > > Signed-off-by: Casey Schaufler <casey.schaufler@intel.com> > --- > security/smack/smack_lsm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c > index 340fc30ad85d..ffa95bcab599 100644 > --- a/security/smack/smack_lsm.c > +++ b/security/smack/smack_lsm.c > @@ -422,7 +422,8 @@ static int smk_ptrace_rule_check(struct task_struct *tracer, > struct task_smack *tsp; > struct smack_known *tracer_known; > > - if ((mode & PTRACE_MODE_NOAUDIT) == 0) { > + if ((mode & PTRACE_MODE_NOAUDIT) == 0 && > + (mode & PTRACE_MODE_SCHED) == 0) { If you ORed PTRACE_MODE_NOAUDIT into the flags when calling the security hook, you could drop this patch, right?
> -----Original Message----- > From: Jann Horn [mailto:jannh@google.com] > Sent: Wednesday, September 26, 2018 2:31 PM > To: Schaufler, Casey <casey.schaufler@intel.com> > Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>; kernel list > <linux-kernel@vger.kernel.org>; linux-security-module <linux-security- > module@vger.kernel.org>; selinux@tycho.nsa.gov; Hansen, Dave > <dave.hansen@intel.com>; Dock, Deneen T <deneen.t.dock@intel.com>; > kristen@linux.intel.com; Arjan van de Ven <arjan@linux.intel.com> > Subject: Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED > > On Wed, Sep 26, 2018 at 10:35 PM Casey Schaufler > <casey.schaufler@intel.com> wrote: > > A ptrace access check with mode PTRACE_MODE_SCHED gets called > > from process switching code. This precludes the use of audit, > > as the locking is incompatible. Don't do audit in the PTRACE_MODE_SCHED > > case. > > > > Signed-off-by: Casey Schaufler <casey.schaufler@intel.com> > > --- > > security/smack/smack_lsm.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c > > index 340fc30ad85d..ffa95bcab599 100644 > > --- a/security/smack/smack_lsm.c > > +++ b/security/smack/smack_lsm.c > > @@ -422,7 +422,8 @@ static int smk_ptrace_rule_check(struct task_struct > *tracer, > > struct task_smack *tsp; > > struct smack_known *tracer_known; > > > > - if ((mode & PTRACE_MODE_NOAUDIT) == 0) { > > + if ((mode & PTRACE_MODE_NOAUDIT) == 0 && > > + (mode & PTRACE_MODE_SCHED) == 0) { > > If you ORed PTRACE_MODE_NOAUDIT into the flags when calling the > security hook, you could drop this patch, right? Yes. Since the PTRACE_MODE_NOAUDIT was in PTRACE_MODE_IBPB in Jiri's previous patch set and not in PTRACE_MODE_SCHED in this one I assumed that there was a good reason for it.
+Jiri On Thu, Sep 27, 2018 at 12:54 AM Schaufler, Casey <casey.schaufler@intel.com> wrote: > > -----Original Message----- > > From: Jann Horn [mailto:jannh@google.com] > > Sent: Wednesday, September 26, 2018 2:31 PM > > To: Schaufler, Casey <casey.schaufler@intel.com> > > Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>; kernel list > > <linux-kernel@vger.kernel.org>; linux-security-module <linux-security- > > module@vger.kernel.org>; selinux@tycho.nsa.gov; Hansen, Dave > > <dave.hansen@intel.com>; Dock, Deneen T <deneen.t.dock@intel.com>; > > kristen@linux.intel.com; Arjan van de Ven <arjan@linux.intel.com> > > Subject: Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED > > > > On Wed, Sep 26, 2018 at 10:35 PM Casey Schaufler > > <casey.schaufler@intel.com> wrote: > > > A ptrace access check with mode PTRACE_MODE_SCHED gets called > > > from process switching code. This precludes the use of audit, > > > as the locking is incompatible. Don't do audit in the PTRACE_MODE_SCHED > > > case. > > > > > > Signed-off-by: Casey Schaufler <casey.schaufler@intel.com> > > > --- > > > security/smack/smack_lsm.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c > > > index 340fc30ad85d..ffa95bcab599 100644 > > > --- a/security/smack/smack_lsm.c > > > +++ b/security/smack/smack_lsm.c > > > @@ -422,7 +422,8 @@ static int smk_ptrace_rule_check(struct task_struct > > *tracer, > > > struct task_smack *tsp; > > > struct smack_known *tracer_known; > > > > > > - if ((mode & PTRACE_MODE_NOAUDIT) == 0) { > > > + if ((mode & PTRACE_MODE_NOAUDIT) == 0 && > > > + (mode & PTRACE_MODE_SCHED) == 0) { > > > > If you ORed PTRACE_MODE_NOAUDIT into the flags when calling the > > security hook, you could drop this patch, right? > > Yes. Since the PTRACE_MODE_NOAUDIT was in PTRACE_MODE_IBPB > in Jiri's previous patch set and not in PTRACE_MODE_SCHED in this one > I assumed that there was a good reason for it. Jiri, was there a good reason for it, and if so, what was it?
On Thu, 27 Sep 2018, Jann Horn wrote: > > Yes. Since the PTRACE_MODE_NOAUDIT was in PTRACE_MODE_IBPB in Jiri's > > previous patch set and not in PTRACE_MODE_SCHED in this one I assumed > > that there was a good reason for it. > > Jiri, was there a good reason for it, and if so, what was it? [ FWIW PTRACE_MODE_NOAUDIT being in PTRACE_MODE_IBPB goes back to original Tim's pre-CRD patchset ] Well, we can't really call out into audit from scheduler code, and the previous versions of the patchsets didn't have PTRACE_MODE_SCHED, so it had to be included in PTRACE_MODE_IBPB in order to make sure we're not calling into audit from context switch code. Or did I misunderstand the question? Thanks,
On Thu, Oct 4, 2018 at 9:47 AM Jiri Kosina <jikos@kernel.org> wrote: > On Thu, 27 Sep 2018, Jann Horn wrote: > > > Yes. Since the PTRACE_MODE_NOAUDIT was in PTRACE_MODE_IBPB in Jiri's > > > previous patch set and not in PTRACE_MODE_SCHED in this one I assumed > > > that there was a good reason for it. > > > > Jiri, was there a good reason for it, and if so, what was it? > > [ FWIW PTRACE_MODE_NOAUDIT being in PTRACE_MODE_IBPB goes back to original > Tim's pre-CRD patchset ] > > Well, we can't really call out into audit from scheduler code, and the > previous versions of the patchsets didn't have PTRACE_MODE_SCHED, so it > had to be included in PTRACE_MODE_IBPB in order to make sure we're not > calling into audit from context switch code. > > Or did I misunderstand the question? If I understand Casey correctly, he is saying that your patch (https://lore.kernel.org/lkml/nycvar.YFH.7.76.1809251437340.15880@cbobk.fhfr.pm/) doesn't include PTRACE_MODE_NOAUDIT for IBPB, but the previous v6 of your patch (https://lore.kernel.org/lkml/nycvar.YFH.7.76.1809121105330.15880@cbobk.fhfr.pm/) did include it, and therefore Casey thinks that there is a specific reason why you removed PTRACE_MODE_NOAUDIT, and therefore Casey is adding special-case logic for PTRACE_MODE_SCHED to Smack when simply using PTRACE_MODE_NOAUDIT would also work. I think that Casey should change ptrace_may_access_sched() to use "mode | PTRACE_MODE_SCHED | PTRACE_MODE_NOAUDIT".
On Thu, 4 Oct 2018, Jann Horn wrote: > > Well, we can't really call out into audit from scheduler code, and the > > previous versions of the patchsets didn't have PTRACE_MODE_SCHED, so it > > had to be included in PTRACE_MODE_IBPB in order to make sure we're not > > calling into audit from context switch code. > > > > Or did I misunderstand the question? > > If I understand Casey correctly, he is saying that your patch > (https://lore.kernel.org/lkml/nycvar.YFH.7.76.1809251437340.15880@cbobk.fhfr.pm/) > doesn't include PTRACE_MODE_NOAUDIT for IBPB, but the previous v6 of > your patch (https://lore.kernel.org/lkml/nycvar.YFH.7.76.1809121105330.15880@cbobk.fhfr.pm/) > did include it, and therefore Casey thinks that there is a specific > reason why you removed PTRACE_MODE_NOAUDIT, Quite honestly, I don't remember. I dont't think there is any deadlock that'd be triggered by this. > and therefore Casey is adding special-case logic for PTRACE_MODE_SCHED > to Smack when simply using PTRACE_MODE_NOAUDIT would also work. > > I think that Casey should change ptrace_may_access_sched() to use > "mode | PTRACE_MODE_SCHED | PTRACE_MODE_NOAUDIT". Agreed, that should work. Thanks,
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 340fc30ad85d..ffa95bcab599 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -422,7 +422,8 @@ static int smk_ptrace_rule_check(struct task_struct *tracer, struct task_smack *tsp; struct smack_known *tracer_known; - if ((mode & PTRACE_MODE_NOAUDIT) == 0) { + if ((mode & PTRACE_MODE_NOAUDIT) == 0 && + (mode & PTRACE_MODE_SCHED) == 0) { smk_ad_init(&ad, func, LSM_AUDIT_DATA_TASK); smk_ad_setfield_u_tsk(&ad, tracer); saip = &ad;