On 05.12.2019 20:33, Casey Schaufler wrote: > On 12/5/2019 9:05 AM, Alexey Budankov wrote: >> Hello Casey, >> >> On 05.12.2019 19:49, Casey Schaufler wrote: >>> On 12/5/2019 8:15 AM, Alexey Budankov wrote: >>>> Currently access to perf_events functionality [1] beyond the scope permitted >>>> by perf_event_paranoid [1] kernel setting is allowed to a privileged process >>>> [2] with CAP_SYS_ADMIN capability enabled in the process effective set [3]. >>>> >>>> This patch set introduces CAP_SYS_PERFMON capability devoted to secure performance >>>> monitoring activity so that CAP_SYS_PERFMON would assist CAP_SYS_ADMIN in its >>>> governing role for perf_events based performance monitoring of a system. >>>> >>>> CAP_SYS_PERFMON aims to harden system security and integrity when monitoring >>>> performance using perf_events subsystem by processes and Perf privileged users >>>> [2], thus decreasing attack surface that is available to CAP_SYS_ADMIN >>>> privileged processes [3]. >>> Are there use cases where you would need CAP_SYS_PERFMON where you >>> would not also need CAP_SYS_ADMIN? If you separate a new capability >> Actually, there are. Perf tool that has record, stat and top modes could run with >> CAP_SYS_PERFMON capability as mentioned below and provide system wide performance >> data. Currently for that to work the tool needs to be granted with CAP_SYS_ADMIN. > > The question isn't whether the tool could use the capability, it's whether > the tool would also need CAP_SYS_ADMIN to be useful. Are there existing > tools that could stop using CAP_SYS_ADMIN in favor of CAP_SYS_PERFMON? > My bet is that any tool that does performance monitoring is going to need > CAP_SYS_ADMIN for other reasons. Yes, sorry. The tool is perf tool (part of kernel tree). If its binary is granted CAP_SYS_ADMIN capability then the tool can collect performance data in system wide mode for some group of unprivileged users. This patch allows replacing CAP_SYS_ADMIN by CAP_SYS_PERFMON e.g. for perf tool and then the tool being granted CAP_SYS_PERFMON could still provide performance data in system wide scope for the same group of unprivileged users. Hope it's got clearer. Feel free to ask more. Thanks, Alexey > >> >>> from CAP_SYS_ADMIN but always have to use CAP_SYS_ADMIN in conjunction >>> with the new capability it is all rather pointless. >>> >>> The scope you've defined for this CAP_SYS_PERFMON is very small. >>> Is there a larger set of privilege checks that might be applicable >>> for it? >> CAP_SYS_PERFMON could be applied broadly, though, this patch set enables record >> and stat mode use cases for system wide performance monitoring in kernel and >> user modes. > > The granularity of capabilities is something we have to watch > very carefully. Sure, CAP_SYS_ADMIN covers a lot of things, but > if we broke it up "properly" we'd have hundreds of capabilities. > If you want control that finely we have SELinux. > >> >> Thanks, >> Alexey >> >>> >>> >>>> CAP_SYS_PERFMON aims to take over CAP_SYS_ADMIN credentials related to >>>> performance monitoring functionality of perf_events and balance amount of >>>> CAP_SYS_ADMIN credentials in accordance with the recommendations provided in >>>> the man page for CAP_SYS_ADMIN [3]: "Note: this capability is overloaded; >>>> see Notes to kernel developers, below." >>>> >>>> For backward compatibility reasons performance monitoring functionality of >>>> perf_events subsystem remains available under CAP_SYS_ADMIN but its usage for >>>> secure performance monitoring use cases is discouraged with respect to the >>>> introduced CAP_SYS_PERFMON capability. >>>> >>>> In the suggested implementation CAP_SYS_PERFMON enables Perf privileged users >>>> [2] to conduct secure performance monitoring using perf_events in the scope >>>> of available online CPUs when executing code in kernel and user modes. >>>> >>>> Possible alternative solution to this capabilities balancing, system security >>>> hardening task could be to use the existing CAP_SYS_PTRACE capability to govern >>>> perf_events' performance monitoring functionality, since process debugging is >>>> similar to performance monitoring with respect to providing insights into >>>> process memory and execution details. However CAP_SYS_PTRACE still provides >>>> users with more credentials than are required for secure performance monitoring >>>> using perf_events subsystem and this excess is avoided by using the dedicated >>>> CAP_SYS_PERFMON capability. >>>> >>>> libcap library utilities [4], [5] and Perf tool can be used to apply >>>> CAP_SYS_PERFMON capability for secure performance monitoring beyond the scope >>>> permitted by system wide perf_event_paranoid kernel setting and below are the >>>> steps to evaluate the advancement suggested by the patch set: >>>> >>>> - patch, build and boot the kernel >>>> - patch, build Perf tool e.g. to /home/user/perf >>>> ... >>>> # git clone git://git.kernel.org/pub/scm/libs/libcap/libcap.git libcap >>>> # pushd libcap >>>> # patch libcap/include/uapi/linux/capabilities.h with [PATCH 1/3] >>>> # make >>>> # pushd progs >>>> # ./setcap "cap_sys_perfmon,cap_sys_ptrace,cap_syslog=ep" /home/user/perf >>>> # ./setcap -v "cap_sys_perfmon,cap_sys_ptrace,cap_syslog=ep" /home/user/perf >>>> /home/user/perf: OK >>>> # ./getcap /home/user/perf >>>> /home/user/perf = cap_sys_ptrace,cap_syslog,cap_sys_perfmon+ep >>>> # echo 2 > /proc/sys/kernel/perf_event_paranoid >>>> # cat /proc/sys/kernel/perf_event_paranoid >>>> 2 >>>> ... >>>> $ /home/user/perf top >>>> ... works as expected ... >>>> $ cat /proc/`pidof perf`/status >>>> Name: perf >>>> Umask: 0002 >>>> State: S (sleeping) >>>> Tgid: 2958 >>>> Ngid: 0 >>>> Pid: 2958 >>>> PPid: 9847 >>>> TracerPid: 0 >>>> Uid: 500 500 500 500 >>>> Gid: 500 500 500 500 >>>> FDSize: 256 >>>> ... >>>> CapInh: 0000000000000000 >>>> CapPrm: 0000004400080000 >>>> CapEff: 0000004400080000 => 01000100 00000000 00001000 00000000 00000000 >>>> cap_sys_perfmon,cap_sys_ptrace,cap_syslog >>>> CapBnd: 0000007fffffffff >>>> CapAmb: 0000000000000000 >>>> NoNewPrivs: 0 >>>> Seccomp: 0 >>>> Speculation_Store_Bypass: thread vulnerable >>>> Cpus_allowed: ff >>>> Cpus_allowed_list: 0-7 >>>> ... >>>> >>>> Usage of cap_sys_perfmon effectively avoids unused credentials excess: >>>> - with cap_sys_admin: >>>> CapEff: 0000007fffffffff => 01111111 11111111 11111111 11111111 11111111 >>>> - with cap_sys_perfmon: >>>> CapEff: 0000004400080000 => 01000100 00000000 00001000 00000000 00000000 >>>> 38 34 19 >>>> sys_perfmon syslog sys_ptrace >>>> >>>> The patch set is for tip perf/core repository: >>>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip perf/core >>>> tip sha1: ceb9e77324fa661b1001a0ae66f061b5fcb4e4e6 >>>> >>>> [1] http://man7.org/linux/man-pages/man2/perf_event_open.2.html >>>> [2] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html >>>> [3] http://man7.org/linux/man-pages/man7/capabilities.7.html >>>> [4] http://man7.org/linux/man-pages/man8/setcap.8.html >>>> [5] https://git.kernel.org/pub/scm/libs/libcap/libcap.git >>>> [6] https://sites.google.com/site/fullycapable/, posix_1003.1e-990310.pdf >>>> >>>> --- >>>> Alexey Budankov (3): >>>> capabilities: introduce CAP_SYS_PERFMON to kernel and user space >>>> perf/core: apply CAP_SYS_PERFMON to CPUs and kernel monitoring >>>> perf tool: extend Perf tool with CAP_SYS_PERFMON support >>>> >>>> include/linux/perf_event.h | 6 ++++-- >>>> include/uapi/linux/capability.h | 10 +++++++++- >>>> security/selinux/include/classmap.h | 4 ++-- >>>> tools/perf/design.txt | 3 ++- >>>> tools/perf/util/cap.h | 4 ++++ >>>> tools/perf/util/evsel.c | 10 +++++----- >>>> tools/perf/util/util.c | 15 +++++++++++++-- >>>> 7 files changed, 39 insertions(+), 13 deletions(-) >>>> >>> > >
