From: Alexey Budankov <alexey.budankov@linux.intel.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>, Andi Kleen <ak@linux.intel.com>,
elena.reshetova@intel.com,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>,
Stephane Eranian <eranian@google.com>,
Namhyung Kim <namhyung@kernel.org>,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 0/3] Introduce CAP_SYS_PERFMON capability for secure Perf users groups
Date: Thu, 5 Dec 2019 20:05:59 +0300 [thread overview]
Message-ID: <d0c6f000-4757-02d8-b114-a35cbb9566ed@linux.intel.com> (raw)
In-Reply-To: <1e836f34-eda3-542d-f7ce-9a3e87ac5e2e@schaufler-ca.com>
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.
> 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.
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(-)
>>
>
>
next prev parent reply other threads:[~2019-12-05 17:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 16:15 [PATCH v1 0/3] Introduce CAP_SYS_PERFMON capability for secure Perf users groups Alexey Budankov
2019-12-05 16:19 ` [PATCH v1 1/3] capabilities: introduce CAP_SYS_PERFMON to kernel and user space Alexey Budankov
2019-12-05 16:21 ` [PATCH v1 2/3] perf/core: apply CAP_SYS_PERFMON to CPUs and kernel monitoring Alexey Budankov
2019-12-05 16:22 ` [PATCH v1 3/3] perf tool: extend Perf tool with CAP_SYS_PERFMON support Alexey Budankov
2019-12-05 16:49 ` [PATCH v1 0/3] Introduce CAP_SYS_PERFMON capability for secure Perf users groups Casey Schaufler
2019-12-05 17:05 ` Alexey Budankov [this message]
2019-12-05 17:33 ` Casey Schaufler
2019-12-05 18:11 ` Andi Kleen
2019-12-05 18:37 ` Alexey Budankov
2019-12-11 10:52 ` Alexey Budankov
2019-12-11 15:24 ` Peter Zijlstra
2019-12-11 17:00 ` Alexey Budankov
2019-12-11 18:09 ` Casey Schaufler
2019-12-11 20:36 ` Andi Kleen
2019-12-11 21:25 ` Casey Schaufler
2019-12-12 14:24 ` Stephen Smalley
2019-12-15 11:53 ` Alexey Budankov
2019-12-11 19:04 ` Stephane Eranian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d0c6f000-4757-02d8-b114-a35cbb9566ed@linux.intel.com \
--to=alexey.budankov@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=casey@schaufler-ca.com \
--cc=elena.reshetova@intel.com \
--cc=eranian@google.com \
--cc=jannh@google.com \
--cc=jolsa@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).