Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED
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.15...@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.15...@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, -- Jiri Kosina SUSE Labs ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED
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, -- Jiri Kosina SUSE Labs ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED
On Thu, Oct 4, 2018 at 9:47 AM Jiri Kosina 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.15...@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.15...@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". ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED
On Wed, Sep 26, 2018 at 10:35 PM Casey Schaufler 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 > --- > 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? ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
RE: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED
> -Original Message- > From: Jann Horn [mailto:ja...@google.com] > Sent: Wednesday, September 26, 2018 2:31 PM > To: Schaufler, Casey > Cc: Kernel Hardening ; kernel list > ; linux-security-module mod...@vger.kernel.org>; selinux@tycho.nsa.gov; Hansen, Dave > ; Dock, Deneen T ; > kris...@linux.intel.com; Arjan van de Ven > Subject: Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED > > On Wed, Sep 26, 2018 at 10:35 PM Casey Schaufler > 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 > > --- > > 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. ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED
+Jiri On Thu, Sep 27, 2018 at 12:54 AM Schaufler, Casey wrote: > > -Original Message- > > From: Jann Horn [mailto:ja...@google.com] > > Sent: Wednesday, September 26, 2018 2:31 PM > > To: Schaufler, Casey > > Cc: Kernel Hardening ; kernel list > > ; linux-security-module > mod...@vger.kernel.org>; selinux@tycho.nsa.gov; Hansen, Dave > > ; Dock, Deneen T ; > > kris...@linux.intel.com; Arjan van de Ven > > Subject: Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED > > > > On Wed, Sep 26, 2018 at 10:35 PM Casey Schaufler > > 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 > > > --- > > > 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? ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
[PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED
From: Casey Schaufler 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 --- 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) { smk_ad_init(&ad, func, LSM_AUDIT_DATA_TASK); smk_ad_setfield_u_tsk(&ad, tracer); saip = &ad; -- 2.17.1 ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.