[PATCH v1 0/3] Introduce CAP_SYS_PERFMON capability for secure Perf users groups
Alexey Budankov
alexey.budankov at linux.intel.com
Thu Dec 5 18:37:30 UTC 2019
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(-)
>>>>
>>>
>
>
More information about the Linux-security-module-archive
mailing list