1 .. _perf_security:
2
3 Perf events and tool security
4 =============================
5
6 Overview
7 --------
8
9 Usage of Performance Counters for Linux (perf_
10 can impose a considerable risk of leaking sens
11 monitored processes. The data leakage is possi
12 direct usage of perf_events system call API [2
13 generated by Perf tool user mode utility (Perf
14 depends on the nature of data that perf_events
15 units (PMU) [2]_ and Perf collect and expose f
16 Collected system and performance data may be s
17 categories:
18
19 1. System hardware and software configuration
20 model and its cache configuration, an amoun
21 its topology, used kernel and Perf versions
22 setup including experiment time, events con
23 line parameters, etc.
24
25 2. User and kernel module paths and their load
26 process and thread names with their PIDs an
27 captured hardware and software events.
28
29 3. Content of kernel software counters (e.g.,
30 faults, CPU migrations), architectural hard
31 (PMC) [8]_ and machine specific registers (
32 execution metrics for various monitored par
33 memory controller (IMC), interconnect (QPI/
34 uncore counters) without direct attribution
35 state.
36
37 4. Content of architectural execution context
38 RBP on x86_64), process user and kernel spa
39 data, content of various architectural MSRs
40 this category.
41
42 Data that belong to the fourth category can po
43 sensitive process data. If PMUs in some monito
44 of execution context registers or data from pr
45 to such monitoring modes requires to be ordere
46 So, perf_events performance monitoring and obs
47 the subject for security access control manage
48
49 perf_events access control
50 -------------------------------
51
52 To perform security checks, the Linux implemen
53 into two categories [6]_ : a) privileged proce
54 ID is 0, referred to as superuser or root), an
55 processes (whose effective UID is nonzero). Pr
56 all kernel security permission checks so perf_
57 monitoring is fully available to privileged pr
58 scope and resource restrictions.
59
60 Unprivileged processes are subject to a full s
61 based on the process's credentials [5]_ (usual
62 effective GID, and supplementary group list).
63
64 Linux divides the privileges traditionally ass
65 into distinct units, known as capabilities [6]
66 independently enabled and disabled on per-thre
67 files of unprivileged users.
68
69 Unprivileged processes with enabled CAP_PERFMO
70 as privileged processes with respect to perf_e
71 monitoring and observability operations, thus,
72 checks in the kernel. CAP_PERFMON implements t
73 privilege [13]_ (POSIX 1003.1e: 2.2.2.39) for
74 observability operations in the kernel and pro
75 performance monitoring and observability in th
76
77 For backward compatibility reasons the access
78 observability operations is also open for CAP_
79 processes but CAP_SYS_ADMIN usage for secure m
80 use cases is discouraged with respect to the C
81 If system audit records [14]_ for a process us
82 API contain denial records of acquiring both C
83 capabilities then providing the process with C
84 is recommended as the preferred secure approac
85 denial logging related to usage of performance
86
87 Prior Linux v5.9 unprivileged processes using
88 are also subject for PTRACE_MODE_READ_REALCRED
89 [7]_ , whose outcome determines whether monito
90 So unprivileged processes provided with CAP_SY
91 effectively permitted to pass the check. Start
92 CAP_SYS_PTRACE capability is not required and
93 be provided for processes to make performance
94 operations.
95
96 Other capabilities being granted to unprivileg
97 effectively enable capturing of additional dat
98 performance analysis of monitored processes or
99 CAP_SYSLOG capability permits reading kernel s
100 /proc/kallsyms file.
101
102 Privileged Perf users groups
103 ---------------------------------
104
105 Mechanisms of capabilities, privileged capabil
106 file system ACLs [10]_ and sudo [15]_ utility
107 dedicated groups of privileged Perf users who
108 performance monitoring and observability witho
109 steps can be taken to create such groups of pr
110
111 1. Create perf_users group of privileged Perf
112 group to Perf tool executable and limit acc
113 other users in the system who are not in th
114
115 ::
116
117 # groupadd perf_users
118 # ls -alhF
119 -rwxr-xr-x 2 root root 11M Oct 19 15:12 p
120 # chgrp perf_users perf
121 # ls -alhF
122 -rwxr-xr-x 2 root perf_users 11M Oct 19 1
123 # chmod o-rwx perf
124 # ls -alhF
125 -rwxr-x--- 2 root perf_users 11M Oct 19 1
126
127 2. Assign the required capabilities to the Per
128 enable members of perf_users group with mon
129 privileges [6]_ :
130
131 ::
132
133 # setcap "cap_perfmon,cap_sys_ptrace,cap_sy
134 # setcap -v "cap_perfmon,cap_sys_ptrace,cap
135 perf: OK
136 # getcap perf
137 perf = cap_sys_ptrace,cap_syslog,cap_perfmo
138
139 If the libcap [16]_ installed doesn't yet supp
140 i.e.:
141
142 ::
143
144 # setcap "38,cap_ipc_lock,cap_sys_ptrace,ca
145
146 Note that you may need to have 'cap_ipc_lock'
147 'perf top', alternatively use 'perf top -m N',
148 it uses for the perf ring buffer, see the memo
149
150 Using a libcap without support for CAP_PERFMON
151 CAP_EFFECTIVE, &val) fail, which will lead the
152 so as a workaround explicitly ask for the 'cyc
153
154 ::
155
156 # perf top -e cycles
157
158 To get kernel and user samples with a perf bin
159
160 As a result, members of perf_users group are c
161 performance monitoring and observability by us
162 configured Perf tool executable that, when exe
163 subsystem scope checks.
164
165 In case Perf tool executable can't be assigned
166 file system is mounted with nosuid option or e
167 not supported by the file system) then creatio
168 privileged environment, naturally shell, is po
169 inherent processes with CAP_PERFMON and other
170 performance monitoring and observability opera
171 environment without limits. Access to the envi
172 utility for members of perf_users group only.
173 environment:
174
175 1. Create shell script that uses capsh utility
176 and other required capabilities into ambien
177 process, lock the process security bits aft
178 SECBIT_NOROOT and SECBIT_NO_CAP_AMBIENT_RAI
179 the process identity to sudo caller of the
180 be a member of perf_users group:
181
182 ::
183
184 # ls -alh /usr/local/bin/perf.shell
185 -rwxr-xr-x. 1 root root 83 Oct 13 23:57 /us
186 # cat /usr/local/bin/perf.shell
187 exec /usr/sbin/capsh --iab=^cap_perfmon --s
188
189 2. Extend sudo policy at /etc/sudoers file wit
190
191 ::
192
193 # grep perf_users /etc/sudoers
194 %perf_users ALL=/usr/local/bin/perf.shel
195
196 3. Check that members of perf_users group have
197 shell and have CAP_PERFMON and other requir
198 in permitted, effective and ambient capabil
199
200 ::
201
202 $ id
203 uid=1003(capsh_test) gid=1004(capsh_test) gr
204 $ sudo perf.shell
205 [sudo] password for capsh_test:
206 $ grep Cap /proc/self/status
207 CapInh: 0000004000000000
208 CapPrm: 0000004000000000
209 CapEff: 0000004000000000
210 CapBnd: 000000ffffffffff
211 CapAmb: 0000004000000000
212 $ capsh --decode=0000004000000000
213 0x0000004000000000=cap_perfmon
214
215 As a result, members of perf_users group have
216 environment where they can use tools employing
217 governed by CAP_PERFMON Linux capability.
218
219 This specific access control management is onl
220 or root running processes with CAP_SETPCAP, CA
221 capabilities.
222
223 Unprivileged users
224 -----------------------------------
225
226 perf_events *scope* and *access* control for u
227 is governed by perf_event_paranoid [2]_ settin
228
229 -1:
230 Impose no *scope* and *access* restrictio
231 performance monitoring. Per-user per-cpu
232 locking limit is ignored when allocating
233 performance data. This is the least secur
234 monitored *scope* is maximized and no per
235 are imposed on *resources* allocated for
236
237 >=0:
238 *scope* includes per-process and system w
239 but excludes raw tracepoints and ftrace f
240 monitoring. CPU and system events happene
241 user or in kernel space can be monitored
242 analysis. Per-user per-cpu perf_event_mlo
243 imposed but ignored for unprivileged proc
244 [6]_ capability.
245
246 >=1:
247 *scope* includes per-process performance
248 excludes system wide performance monitori
249 happened when executing either in user or
250 monitored and captured for later analysis
251 perf_event_mlock_kb locking limit is impo
252 unprivileged processes with CAP_IPC_LOCK
253
254 >=2:
255 *scope* includes per-process performance
256 system events happened when executing in
257 monitored and captured for later analysis
258 perf_event_mlock_kb locking limit is impo
259 unprivileged processes with CAP_IPC_LOCK
260
261 Resource control
262 ---------------------------------
263
264 Open file descriptors
265 +++++++++++++++++++++
266
267 The perf_events system call API [2]_ allocates
268 every configured PMU event. Open file descript
269 accountable resource governed by the RLIMIT_NO
270 (ulimit -n), which is usually derived from the
271 configuring Perf collection for a long list of
272 system, this limit can be easily hit preventin
273 configuration. RLIMIT_NOFILE limit can be incr
274 modifying content of the limits.conf file [12]
275 sampling session (perf record) requires an amo
276 file descriptors that is not less than the num
277 multiplied by the number of monitored CPUs.
278
279 Memory allocation
280 +++++++++++++++++
281
282 The amount of memory available to user process
283 performance monitoring data is governed by the
284 setting. This perf_event specific resource set
285 per-cpu limits of memory allowed for mapping b
286 execute performance monitoring. The setting es
287 RLIMIT_MEMLOCK [11]_ limit, but only for memor
288 specifically for capturing monitored performan
289
290 For example, if a machine has eight cores and
291 is set to 516 KiB, then a user process is prov
292 4128 KiB of memory above the RLIMIT_MEMLOCK li
293 perf_event mmap buffers. In particular, this m
294 wants to start two or more performance monitor
295 required to manually distribute the available
296 monitoring processes, for example, using the -
297 mode option. Otherwise, the first started perf
298 allocates all available 4128 KiB and the other
299 proceed due to the lack of memory.
300
301 RLIMIT_MEMLOCK and perf_event_mlock_kb resourc
302 for processes with the CAP_IPC_LOCK capability
303 privileged users can be provided with memory a
304 perf_events/Perf performance monitoring purpos
305 executable with CAP_IPC_LOCK capability.
306
307 Bibliography
308 ------------
309
310 .. [1] `<https://lwn.net/Articles/337493/>`_
311 .. [2] `<http://man7.org/linux/man-pages/man2/
312 .. [3] `<http://web.eece.maine.edu/~vweaver/pr
313 .. [4] `<https://perf.wiki.kernel.org/index.ph
314 .. [5] `<https://www.kernel.org/doc/html/lates
315 .. [6] `<http://man7.org/linux/man-pages/man7/
316 .. [7] `<http://man7.org/linux/man-pages/man2/
317 .. [8] `<https://en.wikipedia.org/wiki/Hardwar
318 .. [9] `<https://en.wikipedia.org/wiki/Model-s
319 .. [10] `<http://man7.org/linux/man-pages/man5
320 .. [11] `<http://man7.org/linux/man-pages/man2
321 .. [12] `<http://man7.org/linux/man-pages/man5
322 .. [13] `<https://sites.google.com/site/fullyc
323 .. [14] `<http://man7.org/linux/man-pages/man8
324 .. [15] `<https://man7.org/linux/man-pages/man
325 .. [16] `<https://git.kernel.org/pub/scm/libs/
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.