public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Marco Elver <elver@google.com>
Cc: peterz@infradead.org, tglx@linutronix.de, mingo@kernel.org,
	kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
	mingo@redhat.com, acme@kernel.org, mark.rutland@arm.com,
	alexander.shishkin@linux.intel.com, jolsa@redhat.com,
	namhyung@kernel.org, linux-perf-users@vger.kernel.org,
	omosnace@redhat.com, serge@hallyn.com,
	linux-security-module@vger.kernel.org, stable@vger.kernel.org,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH v2] perf: Require CAP_KILL if sigtrap is requested
Date: Thu, 01 Jul 2021 16:41:15 -0500	[thread overview]
Message-ID: <87h7hdn24k.fsf@disp2133> (raw)
In-Reply-To: <20210701083842.580466-1-elver@google.com> (Marco Elver's message of "Thu, 1 Jul 2021 10:38:43 +0200")

Marco Elver <elver@google.com> writes:

> If perf_event_open() is called with another task as target and
> perf_event_attr::sigtrap is set, and the target task's user does not
> match the calling user, also require the CAP_KILL capability.
>
> Otherwise, with the CAP_PERFMON capability alone it would be possible
> for a user to send SIGTRAP signals via perf events to another user's
> tasks. This could potentially result in those tasks being terminated if
> they cannot handle SIGTRAP signals.
>
> Note: The check complements the existing capability check, but is not
> supposed to supersede the ptrace_may_access() check. At a high level we
> now have:
>
> 	capable of CAP_PERFMON and (CAP_KILL if sigtrap)
> 		OR
> 	ptrace_may_access() // also checks for same thread-group and uid

Is there anyway we could have a comment that makes the required
capability checks clear?

Basically I see an inlined version of kill_ok_by_cred being implemented
without the comments on why the various pieces make sense.

Certainly ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS) should not
be a check to allow writing/changing a task.  It needs to be
PTRACE_MODE_ATTACH_REALCREDS, like /proc/self/mem uses.

Now in practice I think your patch probably has the proper checks in
place for sending a signal but it is far from clear.

Eric


> Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events")
> Cc: <stable@vger.kernel.org> # 5.13+
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
> v2:
> * Drop kill_capable() and just check CAP_KILL (reported by Ondrej Mosnacek).
> * Use ns_capable(__task_cred(task)->user_ns, CAP_KILL) to check for
>   capability in target task's ns (reported by Ondrej Mosnacek).
> ---
>  kernel/events/core.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index fe88d6eea3c2..43c99695dc3f 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -12152,10 +12152,23 @@ SYSCALL_DEFINE5(perf_event_open,
>  	}
>  
>  	if (task) {
> +		bool is_capable;
> +
>  		err = down_read_interruptible(&task->signal->exec_update_lock);
>  		if (err)
>  			goto err_file;
>  
> +		is_capable = perfmon_capable();
> +		if (attr.sigtrap) {
> +			/*
> +			 * perf_event_attr::sigtrap sends signals to the other
> +			 * task. Require the current task to have CAP_KILL.
> +			 */
> +			rcu_read_lock();
> +			is_capable &= ns_capable(__task_cred(task)->user_ns, CAP_KILL);
> +			rcu_read_unlock();
> +		}
> +
>  		/*
>  		 * Preserve ptrace permission check for backwards compatibility.
>  		 *
> @@ -12165,7 +12178,7 @@ SYSCALL_DEFINE5(perf_event_open,
>  		 * perf_event_exit_task() that could imply).
>  		 */
>  		err = -EACCES;
> -		if (!perfmon_capable() && !ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS))
> +		if (!is_capable && !ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS))
>  			goto err_cred;
>  	}

  reply	other threads:[~2021-07-01 21:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  8:38 [PATCH v2] perf: Require CAP_KILL if sigtrap is requested Marco Elver
2021-07-01 21:41 ` Eric W. Biederman [this message]
2021-07-02  7:20   ` Marco Elver

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=87h7hdn24k.fsf@disp2133 \
    --to=ebiederm@xmission.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=jolsa@redhat.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=omosnace@redhat.com \
    --cc=peterz@infradead.org \
    --cc=serge@hallyn.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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