1.. _perf_security:
2
3Perf Events and tool security
4=============================
5
6Overview
7--------
8
9Usage of Performance Counters for Linux (perf_events) [1]_ , [2]_ , [3]_ can
10impose a considerable risk of leaking sensitive data accessed by monitored
11processes. The data leakage is possible both in scenarios of direct usage of
12perf_events system call API [2]_ and over data files generated by Perf tool user
13mode utility (Perf) [3]_ , [4]_ . The risk depends on the nature of data that
14perf_events performance monitoring units (PMU) [2]_ collect and expose for
15performance analysis. Having that said perf_events/Perf performance monitoring
16is the subject for security access control management [5]_ .
17
18perf_events/Perf access control
19-------------------------------
20
21To perform security checks, the Linux implementation splits processes into two
22categories [6]_ : a) privileged processes (whose effective user ID is 0, referred
23to as superuser or root), and b) unprivileged processes (whose effective UID is
24nonzero). Privileged processes bypass all kernel security permission checks so
25perf_events performance monitoring is fully available to privileged processes
26without access, scope and resource restrictions.
27
28Unprivileged processes are subject to a full security permission check based on
29the process's credentials [5]_ (usually: effective UID, effective GID, and
30supplementary group list).
31
32Linux divides the privileges traditionally associated with superuser into
33distinct units, known as capabilities [6]_ , which can be independently enabled
34and disabled on per-thread basis for processes and files of unprivileged users.
35
36Unprivileged processes with enabled CAP_SYS_ADMIN capability are treated as
37privileged processes with respect to perf_events performance monitoring and
38bypass *scope* permissions checks in the kernel.
39
40Unprivileged processes using perf_events system call API is also subject for
41PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose outcome
42determines whether monitoring is permitted. So unprivileged processes provided
43with CAP_SYS_PTRACE capability are effectively permitted to pass the check.
44
45Other capabilities being granted to unprivileged processes can effectively
46enable capturing of additional data required for later performance analysis of
47monitored processes or a system. For example, CAP_SYSLOG capability permits
48reading kernel space memory addresses from /proc/kallsyms file.
49
50perf_events/Perf unprivileged users
51-----------------------------------
52
53perf_events/Perf *scope* and *access* control for unprivileged processes is
54governed by perf_event_paranoid [2]_ setting:
55
56-1:
57     Impose no *scope* and *access* restrictions on using perf_events performance
58     monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
59     ignored when allocating memory buffers for storing performance data.
60     This is the least secure mode since allowed monitored *scope* is
61     maximized and no perf_events specific limits are imposed on *resources*
62     allocated for performance monitoring.
63
64>=0:
65     *scope* includes per-process and system wide performance monitoring
66     but excludes raw tracepoints and ftrace function tracepoints monitoring.
67     CPU and system events happened when executing either in user or
68     in kernel space can be monitored and captured for later analysis.
69     Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
70     ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
71
72>=1:
73     *scope* includes per-process performance monitoring only and excludes
74     system wide performance monitoring. CPU and system events happened when
75     executing either in user or in kernel space can be monitored and
76     captured for later analysis. Per-user per-cpu perf_event_mlock_kb
77     locking limit is imposed but ignored for unprivileged processes with
78     CAP_IPC_LOCK capability.
79
80>=2:
81     *scope* includes per-process performance monitoring only. CPU and system
82     events happened when executing in user space only can be monitored and
83     captured for later analysis. Per-user per-cpu perf_event_mlock_kb
84     locking limit is imposed but ignored for unprivileged processes with
85     CAP_IPC_LOCK capability.
86
87Bibliography
88------------
89
90.. [1] `<https://lwn.net/Articles/337493/>`_
91.. [2] `<http://man7.org/linux/man-pages/man2/perf_event_open.2.html>`_
92.. [3] `<http://web.eece.maine.edu/~vweaver/projects/perf_events/>`_
93.. [4] `<https://perf.wiki.kernel.org/index.php/Main_Page>`_
94.. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
95.. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
96.. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_
97
98