| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <a81248c5-971a-9d3f-6df4-e6335384fe7f@schaufler-ca.com>
Date: Thu, 5 Dec 2019 09:33:15 -0800
From: Casey Schaufler <casey@...aufler-ca.com>
To: Alexey Budankov <alexey.budankov@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Ingo Molnar <mingo@...hat.com>
Cc: Jiri Olsa <jolsa@...hat.com>, Andi Kleen <ak@...ux.intel.com>,
elena.reshetova@...el.com,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jann Horn <jannh@...gle.com>,
Kees Cook <keescook@...omium.org>,
Stephane Eranian <eranian@...gle.com>,
Namhyung Kim <namhyung@...nel.org>,
linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>,
Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v1 0/3] Introduce CAP_SYS_PERFMON capability for secure
Perf users groups
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.
>
>> 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(-)
>>>
>>
Powered by blists - more mailing lists