326 lines · plain
1.. _perf_security:2 3Perf events and tool security4=============================5 6Overview7--------8 9Usage of Performance Counters for Linux (perf_events) [1]_ , [2]_ , [3]_10can impose a considerable risk of leaking sensitive data accessed by11monitored processes. The data leakage is possible both in scenarios of12direct usage of perf_events system call API [2]_ and over data files13generated by Perf tool user mode utility (Perf) [3]_ , [4]_ . The risk14depends on the nature of data that perf_events performance monitoring15units (PMU) [2]_ and Perf collect and expose for performance analysis.16Collected system and performance data may be split into several17categories:18 191. System hardware and software configuration data, for example: a CPU20 model and its cache configuration, an amount of available memory and21 its topology, used kernel and Perf versions, performance monitoring22 setup including experiment time, events configuration, Perf command23 line parameters, etc.24 252. User and kernel module paths and their load addresses with sizes,26 process and thread names with their PIDs and TIDs, timestamps for27 captured hardware and software events.28 293. Content of kernel software counters (e.g., for context switches, page30 faults, CPU migrations), architectural hardware performance counters31 (PMC) [8]_ and machine specific registers (MSR) [9]_ that provide32 execution metrics for various monitored parts of the system (e.g.,33 memory controller (IMC), interconnect (QPI/UPI) or peripheral (PCIe)34 uncore counters) without direct attribution to any execution context35 state.36 374. Content of architectural execution context registers (e.g., RIP, RSP,38 RBP on x86_64), process user and kernel space memory addresses and39 data, content of various architectural MSRs that capture data from40 this category.41 42Data that belong to the fourth category can potentially contain43sensitive process data. If PMUs in some monitoring modes capture values44of execution context registers or data from process memory then access45to such monitoring modes requires to be ordered and secured properly.46So, perf_events performance monitoring and observability operations are47the subject for security access control management [5]_ .48 49perf_events access control50-------------------------------51 52To perform security checks, the Linux implementation splits processes53into two categories [6]_ : a) privileged processes (whose effective user54ID is 0, referred to as superuser or root), and b) unprivileged55processes (whose effective UID is nonzero). Privileged processes bypass56all kernel security permission checks so perf_events performance57monitoring is fully available to privileged processes without access,58scope and resource restrictions.59 60Unprivileged processes are subject to a full security permission check61based on the process's credentials [5]_ (usually: effective UID,62effective GID, and supplementary group list).63 64Linux divides the privileges traditionally associated with superuser65into distinct units, known as capabilities [6]_ , which can be66independently enabled and disabled on per-thread basis for processes and67files of unprivileged users.68 69Unprivileged processes with enabled CAP_PERFMON capability are treated70as privileged processes with respect to perf_events performance71monitoring and observability operations, thus, bypass *scope* permissions72checks in the kernel. CAP_PERFMON implements the principle of least73privilege [13]_ (POSIX 1003.1e: 2.2.2.39) for performance monitoring and74observability operations in the kernel and provides a secure approach to75performance monitoring and observability in the system.76 77For backward compatibility reasons the access to perf_events monitoring and78observability operations is also open for CAP_SYS_ADMIN privileged79processes but CAP_SYS_ADMIN usage for secure monitoring and observability80use cases is discouraged with respect to the CAP_PERFMON capability.81If system audit records [14]_ for a process using perf_events system call82API contain denial records of acquiring both CAP_PERFMON and CAP_SYS_ADMIN83capabilities then providing the process with CAP_PERFMON capability singly84is recommended as the preferred secure approach to resolve double access85denial logging related to usage of performance monitoring and observability.86 87Prior Linux v5.9 unprivileged processes using perf_events system call88are also subject for PTRACE_MODE_READ_REALCREDS ptrace access mode check89[7]_ , whose outcome determines whether monitoring is permitted.90So unprivileged processes provided with CAP_SYS_PTRACE capability are91effectively permitted to pass the check. Starting from Linux v5.992CAP_SYS_PTRACE capability is not required and CAP_PERFMON is enough to93be provided for processes to make performance monitoring and observability94operations.95 96Other capabilities being granted to unprivileged processes can97effectively enable capturing of additional data required for later98performance analysis of monitored processes or a system. For example,99CAP_SYSLOG capability permits reading kernel space memory addresses from100/proc/kallsyms file.101 102Privileged Perf users groups103---------------------------------104 105Mechanisms of capabilities, privileged capability-dumb files [6]_,106file system ACLs [10]_ and sudo [15]_ utility can be used to create107dedicated groups of privileged Perf users who are permitted to execute108performance monitoring and observability without limits. The following109steps can be taken to create such groups of privileged Perf users.110 1111. Create perf_users group of privileged Perf users, assign perf_users112 group to Perf tool executable and limit access to the executable for113 other users in the system who are not in the perf_users group:114 115::116 117 # groupadd perf_users118 # ls -alhF119 -rwxr-xr-x 2 root root 11M Oct 19 15:12 perf120 # chgrp perf_users perf121 # ls -alhF122 -rwxr-xr-x 2 root perf_users 11M Oct 19 15:12 perf123 # chmod o-rwx perf124 # ls -alhF125 -rwxr-x--- 2 root perf_users 11M Oct 19 15:12 perf126 1272. Assign the required capabilities to the Perf tool executable file and128 enable members of perf_users group with monitoring and observability129 privileges [6]_ :130 131::132 133 # setcap "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" perf134 # setcap -v "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" perf135 perf: OK136 # getcap perf137 perf = cap_sys_ptrace,cap_syslog,cap_perfmon+ep138 139If the libcap [16]_ installed doesn't yet support "cap_perfmon", use "38" instead,140i.e.:141 142::143 144 # setcap "38,cap_ipc_lock,cap_sys_ptrace,cap_syslog=ep" perf145 146Note that you may need to have 'cap_ipc_lock' in the mix for tools such as147'perf top', alternatively use 'perf top -m N', to reduce the memory that148it uses for the perf ring buffer, see the memory allocation section below.149 150Using a libcap without support for CAP_PERFMON will make cap_get_flag(caps, 38,151CAP_EFFECTIVE, &val) fail, which will lead the default event to be 'cycles:u',152so as a workaround explicitly ask for the 'cycles' event, i.e.:153 154::155 156 # perf top -e cycles157 158To get kernel and user samples with a perf binary with just CAP_PERFMON.159 160As a result, members of perf_users group are capable of conducting161performance monitoring and observability by using functionality of the162configured Perf tool executable that, when executes, passes perf_events163subsystem scope checks.164 165In case Perf tool executable can't be assigned required capabilities (e.g.166file system is mounted with nosuid option or extended attributes are167not supported by the file system) then creation of the capabilities168privileged environment, naturally shell, is possible. The shell provides169inherent processes with CAP_PERFMON and other required capabilities so that170performance monitoring and observability operations are available in the171environment without limits. Access to the environment can be open via sudo172utility for members of perf_users group only. In order to create such173environment:174 1751. Create shell script that uses capsh utility [16]_ to assign CAP_PERFMON176 and other required capabilities into ambient capability set of the shell177 process, lock the process security bits after enabling SECBIT_NO_SETUID_FIXUP,178 SECBIT_NOROOT and SECBIT_NO_CAP_AMBIENT_RAISE bits and then change179 the process identity to sudo caller of the script who should essentially180 be a member of perf_users group:181 182::183 184 # ls -alh /usr/local/bin/perf.shell185 -rwxr-xr-x. 1 root root 83 Oct 13 23:57 /usr/local/bin/perf.shell186 # cat /usr/local/bin/perf.shell187 exec /usr/sbin/capsh --iab=^cap_perfmon --secbits=239 --user=$SUDO_USER -- -l188 1892. Extend sudo policy at /etc/sudoers file with a rule for perf_users group:190 191::192 193 # grep perf_users /etc/sudoers194 %perf_users ALL=/usr/local/bin/perf.shell195 1963. Check that members of perf_users group have access to the privileged197 shell and have CAP_PERFMON and other required capabilities enabled198 in permitted, effective and ambient capability sets of an inherent process:199 200::201 202 $ id203 uid=1003(capsh_test) gid=1004(capsh_test) groups=1004(capsh_test),1000(perf_users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023204 $ sudo perf.shell205 [sudo] password for capsh_test:206 $ grep Cap /proc/self/status207 CapInh: 0000004000000000208 CapPrm: 0000004000000000209 CapEff: 0000004000000000210 CapBnd: 000000ffffffffff211 CapAmb: 0000004000000000212 $ capsh --decode=0000004000000000213 0x0000004000000000=cap_perfmon214 215As a result, members of perf_users group have access to the privileged216environment where they can use tools employing performance monitoring APIs217governed by CAP_PERFMON Linux capability.218 219This specific access control management is only available to superuser220or root running processes with CAP_SETPCAP, CAP_SETFCAP [6]_221capabilities.222 223Unprivileged users224-----------------------------------225 226perf_events *scope* and *access* control for unprivileged processes227is governed by perf_event_paranoid [2]_ setting:228 229-1:230 Impose no *scope* and *access* restrictions on using perf_events231 performance monitoring. Per-user per-cpu perf_event_mlock_kb [2]_232 locking limit is ignored when allocating memory buffers for storing233 performance data. This is the least secure mode since allowed234 monitored *scope* is maximized and no perf_events specific limits235 are imposed on *resources* allocated for performance monitoring.236 237>=0:238 *scope* includes per-process and system wide performance monitoring239 but excludes raw tracepoints and ftrace function tracepoints240 monitoring. CPU and system events happened when executing either in241 user or in kernel space can be monitored and captured for later242 analysis. Per-user per-cpu perf_event_mlock_kb locking limit is243 imposed but ignored for unprivileged processes with CAP_IPC_LOCK244 [6]_ capability.245 246>=1:247 *scope* includes per-process performance monitoring only and248 excludes system wide performance monitoring. CPU and system events249 happened when executing either in user or in kernel space can be250 monitored and captured for later analysis. Per-user per-cpu251 perf_event_mlock_kb locking limit is imposed but ignored for252 unprivileged processes with CAP_IPC_LOCK capability.253 254>=2:255 *scope* includes per-process performance monitoring only. CPU and256 system events happened when executing in user space only can be257 monitored and captured for later analysis. Per-user per-cpu258 perf_event_mlock_kb locking limit is imposed but ignored for259 unprivileged processes with CAP_IPC_LOCK capability.260 261Resource control262---------------------------------263 264Open file descriptors265+++++++++++++++++++++266 267The perf_events system call API [2]_ allocates file descriptors for268every configured PMU event. Open file descriptors are a per-process269accountable resource governed by the RLIMIT_NOFILE [11]_ limit270(ulimit -n), which is usually derived from the login shell process. When271configuring Perf collection for a long list of events on a large server272system, this limit can be easily hit preventing required monitoring273configuration. RLIMIT_NOFILE limit can be increased on per-user basis274modifying content of the limits.conf file [12]_ . Ordinarily, a Perf275sampling session (perf record) requires an amount of open perf_event276file descriptors that is not less than the number of monitored events277multiplied by the number of monitored CPUs.278 279Memory allocation280+++++++++++++++++281 282The amount of memory available to user processes for capturing283performance monitoring data is governed by the perf_event_mlock_kb [2]_284setting. This perf_event specific resource setting defines overall285per-cpu limits of memory allowed for mapping by the user processes to286execute performance monitoring. The setting essentially extends the287RLIMIT_MEMLOCK [11]_ limit, but only for memory regions mapped288specifically for capturing monitored performance events and related data.289 290For example, if a machine has eight cores and perf_event_mlock_kb limit291is set to 516 KiB, then a user process is provided with 516 KiB * 8 =2924128 KiB of memory above the RLIMIT_MEMLOCK limit (ulimit -l) for293perf_event mmap buffers. In particular, this means that, if the user294wants to start two or more performance monitoring processes, the user is295required to manually distribute the available 4128 KiB between the296monitoring processes, for example, using the --mmap-pages Perf record297mode option. Otherwise, the first started performance monitoring process298allocates all available 4128 KiB and the other processes will fail to299proceed due to the lack of memory.300 301RLIMIT_MEMLOCK and perf_event_mlock_kb resource constraints are ignored302for processes with the CAP_IPC_LOCK capability. Thus, perf_events/Perf303privileged users can be provided with memory above the constraints for304perf_events/Perf performance monitoring purpose by providing the Perf305executable with CAP_IPC_LOCK capability.306 307Bibliography308------------309 310.. [1] `<https://lwn.net/Articles/337493/>`_311.. [2] `<http://man7.org/linux/man-pages/man2/perf_event_open.2.html>`_312.. [3] `<http://web.eece.maine.edu/~vweaver/projects/perf_events/>`_313.. [4] `<https://perf.wiki.kernel.org/index.php/Main_Page>`_314.. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_315.. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_316.. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_317.. [8] `<https://en.wikipedia.org/wiki/Hardware_performance_counter>`_318.. [9] `<https://en.wikipedia.org/wiki/Model-specific_register>`_319.. [10] `<http://man7.org/linux/man-pages/man5/acl.5.html>`_320.. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_321.. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_322.. [13] `<https://sites.google.com/site/fullycapable>`_323.. [14] `<http://man7.org/linux/man-pages/man8/auditd.8.html>`_324.. [15] `<https://man7.org/linux/man-pages/man8/sudo.8.html>`_325.. [16] `<https://git.kernel.org/pub/scm/libs/libcap/libcap.git/>`_326