lkml.org 
[lkml]   [2018]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file
On Monday, November 19, 2018 6:42 AM, Alexey Budankov <alexey.budankov@linux.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@linutronix.de
> Signed-off-by: Alexey Budankov alexey.budankov@linux.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

\
 
 \ /
  Last update: 2018-11-19 11:37    [W:0.094 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site