public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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;
> 


  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