[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aDN4nC6p93nK7ILVP3EH-Y4RcKK4KH0ppQKFkIgxTVxkfbOHWjAYJXdTeuq39nbPkySKItZ_8VHN2PfQS_T08GBzeooD5cvc2Xd8oZxSp9s=@protonmail.ch>
Date: Mon, 19 Nov 2018 10:35:59 +0000
From: Jordan Glover <Golden_Miller83@...tonmail.ch>
To: Alexey Budankov <alexey.budankov@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>, Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Arnaldo Carvalho de Melo <acme@...nel.org>, Andi Kleen <ak@...ux.intel.com>, Jonatan Corbet <corbet@....net>, Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...hat.com>, Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>, Tvrtko Ursulin <tursulin@...ulin.net>, linux-kernel <linux-kernel@...r.kernel.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file
On Monday, November 19, 2018 6:42 AM, Alexey Budankov <alexey.budankov@...ux.intel.com> wrote:
> Implement initial version of perf-security.rst documentation file
> initially covering security concerns related to PCL/Perf performance
> monitoring in multiuser environments.
>
> Suggested-by: Thomas Gleixner tglx@...utronix.de
> Signed-off-by: Alexey Budankov alexey.budankov@...ux.intel.com
>
> Documentation/admin-guide/perf-security.rst | 83 +++++++++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
>
> diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
> new file mode 100644
> index 000000000000..b9564066e686
> --- /dev/null
> +++ b/Documentation/admin-guide/perf-security.rst
> @@ -0,0 +1,83 @@
> +.. perf_security:
> +
> +PCL/Perf security
> +=================
> +
> +Overview
> +--------
> +
> +Usage of Performance Counters for Linux (PCL) [1] , [2]_ , [3]_ can impose a+considerable risk of leaking sensitive data accessed by monitored processes.
> +The data leakage is possible both in scenarios of direct usage of PCL system
> +call API [2]_ and over data files generated by Perf tool user mode utility
> +(Perf) [3]_ , [4]_ . The risk depends on the nature of data that PCL performance
> +monitoring units (PMU) [2]_ collect and expose for performance analysis.
> +Having that said PCL/Perf performance monitoring is the subject for security
> +access control management [5]_ .
> +
> +PCL/Perf access control
> +-----------------------
> +
> +For the purpose of performing security checks 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 PCL performance monitoring is fully available to
> +privileged processes without access, scope and resource restrictions.
> +Unprivileged processes are subject to full security permission check based
> +on the process's credentials [5]_ (usually: effective UID, effective GID,
> +and supplementary group list).
> +
> +PCL/Perf unprivileged users
> +---------------------------
> +
> +PCL/Perf scope and access control for unprivileged processes is governed by
> +perf_event_paranoid [2]_ setting:
> +
> +-1:
>
> - Impose no *scope* and *access* restrictions on using PCL performance
>
>
> - monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
>
>
> - ignored when allocating memory buffers for storing performance data.
>
>
> - This is the least secure mode since allowed monitored *scope* is
>
>
> - maximized and no PCL specific limits are imposed on *resources*
>
>
> - allocated for performance monitoring.
>
>
> -
>
> +>=0:
>
> - *scope* includes per-process and system wide performance monitoring
>
>
> - but excludes raw tracepoints and ftrace function tracepoints monitoring.
>
>
> - CPU and system events happened when executing either in user or
>
>
> - in kernel space can be monitored and captured for later analysis.
>
>
> - Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
>
>
> - ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
>
>
> -
>
> +>=1:
>
> - *scope* includes per-process performance monitoring only and excludes
>
>
> - system wide performance monitoring. CPU and system events happened when
>
>
> - executing either in user or in kernel space can be monitored and
>
>
> - captured for later analysis. Per-user per-cpu perf_event_mlock_kb
>
>
> - locking limit is imposed but ignored for unprivileged processes with
>
>
> - CAP_IPC_LOCK capability.
>
>
> -
>
> +>=2:
>
> - *scope* includes per-process performance monitoring only. CPU and system
>
>
> - events happened when executing in user space only can be monitored and
>
>
> - captured for later analysis. Per-user per-cpu perf_event_mlock_kb
>
>
> - locking limit is imposed but ignored for unprivileged processes with
>
>
> - CAP_IPC_LOCK capability.
>
>
> -
>
> +>=3:
>
> - Restrict *access* to PCL performance monitoring for unprivileged processes.
>
>
> - This is the default on Debian and Android [7]_ , [8]_ .
AFAIK there is no support for '+>=3' in mainline kernel[1].
Debian and Android use out-of-tree patch for that[2].
Maybe someone should upstream it?
Jordan
[1] https://github.com/torvalds/linux/blob/master/kernel/events/core.c#L395
[2] https://salsa.debian.org/kernel-team/linux/blob/master/debian/patches/features/all/security-perf-allow-further-restriction-of-perf_event_open.patch
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
