From: Tim Chen <tim.c.chen@linux.intel.com>
To: Jiri Kosina <jikos@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
Oleg Nesterov <oleg@redhat.com>,
Casey Schaufler <casey.schaufler@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks
Date: Tue, 4 Sep 2018 10:26:43 -0700 [thread overview]
Message-ID: <31436186-88da-324e-88a0-8fdca7bf60ac@linux.intel.com> (raw)
In-Reply-To: <alpine.LRH.2.00.1809041639340.14475@gjva.wvxbf.pm>
On 09/04/2018 07:40 AM, Jiri Kosina wrote:
> From: Jiri Kosina <jkosina@suse.cz>
>
> Current ptrace_may_access() implementation assumes that the 'source' task is
> always the caller (current).
>
> Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
> tasks.
Casey recently has proposed putting the decision making of whether to
do IBPB in the security module.
https://lwn.net/ml/kernel-hardening/20180815235355.14908-4-casey.schaufler@intel.com/
That will have the advantage of giving the administrator a more flexibility
of when to turn on IBPB. The policy is very similar to what you have proposed here
but I think the security module is a more appropriate place for the security policy.
Thanks.
Tim
>
> Originally-by: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>
> Sorry for the resend, my pine is buggered and broke threading.
>
> include/linux/ptrace.h | 12 ++++++++++++
> kernel/ptrace.c | 13 ++++++++++---
> 2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
> index 4f36431c380b..09744d4113fb 100644
> --- a/include/linux/ptrace.h
> +++ b/include/linux/ptrace.h
> @@ -87,6 +87,18 @@ extern void exit_ptrace(struct task_struct *tracer, struct list_head *dead);
> */
> extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
>
> +/**
> + * ___ptrace_may_access - variant of ptrace_may_access that can be used
> + * between two arbitrary tasks
> + * @curr: source task
> + * @task: target task
> + * @mode: selects type of access and caller credentials
> + *
> + * Returns true on success, false on denial.
> + */
> +extern int ___ptrace_may_access(struct task_struct *curr, struct task_struct *task,
> + unsigned int mode);
> +
> static inline int ptrace_reparented(struct task_struct *child)
> {
> return !same_thread_group(child->real_parent, child->parent);
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index 21fec73d45d4..07ff6685ebed 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -268,9 +268,10 @@ static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
> }
>
> /* Returns 0 on success, -errno on denial. */
> -static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> +int ___ptrace_may_access(struct task_struct *curr, struct task_struct *task,
> + unsigned int mode)
> {
> - const struct cred *cred = current_cred(), *tcred;
> + const struct cred *cred, *tcred;
> struct mm_struct *mm;
> kuid_t caller_uid;
> kgid_t caller_gid;
> @@ -290,9 +291,10 @@ static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> */
>
> /* Don't let security modules deny introspection */
> - if (same_thread_group(task, current))
> + if (same_thread_group(task, curr))
> return 0;
> rcu_read_lock();
> + cred = __task_cred(curr);
> if (mode & PTRACE_MODE_FSCREDS) {
> caller_uid = cred->fsuid;
> caller_gid = cred->fsgid;
> @@ -331,6 +333,11 @@ static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> return security_ptrace_access_check(task, mode);
> }
>
> +static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> +{
> + return ___ptrace_may_access(current, task, mode);
> +}
> +
> bool ptrace_may_access(struct task_struct *task, unsigned int mode)
> {
> int err;
>
next prev parent reply other threads:[~2018-09-04 17:26 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-31 20:56 [PATCH] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation Jiri Kosina
2018-09-03 8:51 ` Jiri Kosina
2018-09-03 12:45 ` [PATCH v2 0/3] Harden spectrev2 userspace-userspace protection Jiri Kosina
2018-09-04 14:23 ` [PATCH v3 " Jiri Kosina
2018-09-04 14:40 ` [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks Jiri Kosina
2018-09-04 16:13 ` Thomas Gleixner
2018-09-04 16:21 ` Thomas Gleixner
2018-09-04 17:26 ` Tim Chen [this message]
2018-09-04 17:35 ` Jiri Kosina
2018-09-04 18:10 ` Schaufler, Casey
2018-09-04 18:48 ` Jiri Kosina
2018-09-04 23:26 ` Tim Chen
2018-09-05 6:22 ` Jiri Kosina
2018-09-05 15:58 ` Andi Kleen
2018-09-05 18:04 ` Andrea Arcangeli
2018-09-05 18:29 ` Jiri Kosina
2018-09-05 18:40 ` Andrea Arcangeli
2018-09-05 18:42 ` Jiri Kosina
2018-09-05 19:03 ` Peter Zijlstra
2018-09-05 19:27 ` Schaufler, Casey
2018-09-05 20:02 ` Jiri Kosina
2018-09-05 18:26 ` Thomas Gleixner
2018-09-05 18:35 ` Jiri Kosina
2018-09-04 23:37 ` Andrea Arcangeli
2018-09-05 1:00 ` Schaufler, Casey
2018-09-05 2:38 ` Andrea Arcangeli
2018-09-05 8:00 ` Peter Zijlstra
2018-09-05 15:37 ` Schaufler, Casey
2018-09-05 7:51 ` Peter Zijlstra
2018-09-04 14:42 ` [PATCH v3 2/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak Jiri Kosina
2018-09-04 16:18 ` Thomas Gleixner
2018-09-05 7:59 ` Peter Zijlstra
2018-09-05 8:02 ` Jiri Kosina
2018-09-05 9:40 ` Peter Zijlstra
2018-09-05 7:52 ` Peter Zijlstra
2018-09-05 7:55 ` Jiri Kosina
2018-09-04 14:42 ` [PATCH v3 3/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation Jiri Kosina
-- strict thread matches above, loose matches on Subject: below --
2018-09-04 14:24 [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks Jiri Kosina
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=31436186-88da-324e-88a0-8fdca7bf60ac@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=aarcange@redhat.com \
--cc=casey.schaufler@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@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