From: Jonathan Corbet <corbet@lwn.net>
To: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Andi Kleen <ak@linux.intel.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
linux-kernel <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v4 1/2] Documentation/admin-guide: introduce perf-security.rst file
Date: Tue, 27 Nov 2018 11:11:48 -0700 [thread overview]
Message-ID: <20181127111148.75746f02@lwn.net> (raw)
In-Reply-To: <b1a4fa08-482d-0fcc-c798-efb9a9894a47@linux.intel.com>
On Tue, 27 Nov 2018 11:15:37 +0300
Alexey Budankov <alexey.budankov@linux.intel.com> wrote:
> +To perform security checks, the Linux implementation splits processes into two
> +categories [6]_ : a) privileged processes (whose effective user ID is 0, referred
> +to as superuser or root), and b) unprivileged processes (whose effective UID is
> +nonzero). Privileged processes bypass all kernel security permission checks so
> +perf_events performance monitoring is fully available to privileged processes
> +without access, scope and resource restrictions.
> +
> +Unprivileged processes are subject to a full security permission check based on
> +the process's credentials [5]_ (usually: effective UID, effective GID, and
> +supplementary group list).
> +
> +Linux divides the privileges traditionally associated with superuser into
> +distinct units, known as capabilities [6]_ , which can be independently enabled
> +and disabled on per-thread basis for processes and files of unprivileged users.
> +
> +Unprivileged processes with enabled CAP_SYS_ADMIN capability are treated as
> +privileged processes with respect to perf_events performance monitoring and
> +bypass *scope* permissions checks in the kernel.
> +
> +Unprivileged processes using perf_events system call API is also subject for
> +PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose outcome
> +determines whether monitoring is permitted. So unprivileged processes provided
> +with CAP_SYS_PTRACE capability are effectively permitted to pass the check.
It's good to have more information here. I could certainly quibble
further with things - a process with CAP_SYS_ADMIN is not "unprivileged"!
- but I don't want to stand in the way of this any further. I *would*
still like to see an ack from the perf world, though.
With regard to Kees's comment on merging the two patches; I would probably
add the new document to index.rst in the same patch, but it doesn't matter
that much. Not worth redoing the patch just for that.
jon
next prev parent reply other threads:[~2018-11-27 18:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-27 8:11 [PATCH v4 0/2] Documentation/admin-guide: introduce perf-security.rst file and extend perf_event_paranoid documentation Alexey Budankov
2018-11-27 8:15 ` [PATCH v4 1/2] Documentation/admin-guide: introduce perf-security.rst file Alexey Budankov
2018-11-27 18:11 ` Jonathan Corbet [this message]
2018-11-27 19:13 ` Alexey Budankov
2018-12-03 9:42 ` Alexey Budankov
2018-12-06 1:10 ` Kees Cook
2018-12-06 10:45 ` Alexey Budankov
2018-12-06 16:57 ` Jonathan Corbet
2018-11-27 8:16 ` [PATCH v4 2/2] Documentation/admin-guide: update admin-guide index.rst Alexey Budankov
2018-11-27 17:23 ` Kees Cook
2018-11-27 19:16 ` Alexey Budankov
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=20181127111148.75746f02@lwn.net \
--to=corbet@lwn.net \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexey.budankov@linux.intel.com \
--cc=jannh@google.com \
--cc=jolsa@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tursulin@ursulin.net \
/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