Currently access to perf_events, i915_perf and other performance monitoring and
observability subsystems of the kernel is open for a privileged process [1] with
CAP_SYS_ADMIN capability enabled in the process effective set [2].
This patch set introduces CAP_SYS_PERFMON capability devoted to secure system
performance monitoring and observability operations so that CAP_SYS_PERFMON would
assist CAP_SYS_ADMIN capability in its governing role for perf_events, i915_perf
and other performance monitoring and observability subsystems of the kernel.
CAP_SYS_PERFMON intends to meet the demand to secure system performance monitoring
and observability operations in security sensitive, restricted, production
environments (e.g. HPC clusters, cloud and virtual compute environments) where root
or CAP_SYS_ADMIN credentials are not available to mass users of a system because
of security considerations.
CAP_SYS_PERFMON intends to harden system security and integrity during system
performance monitoring and observability operations by decreasing attack surface
that is available to CAP_SYS_ADMIN privileged processes [2].
CAP_SYS_PERFMON intends to take over CAP_SYS_ADMIN credentials related to system
performance monitoring and observability operations and balance amount of
CAP_SYS_ADMIN credentials following the recommendations in the capabilities man
page [2] for CAP_SYS_ADMIN: "Note: this capability is overloaded; see Notes to
kernel developers, below."
For backward compatibility reasons access to system performance monitoring and
observability subsystems of the kernel remains open for CAP_SYS_ADMIN privileged
processes but CAP_SYS_ADMIN capability usage for secure system performance
monitoring and observability operations is discouraged with respect to the
introduced CAP_SYS_PERFMON capability.
The patch set is for tip perf/core repository:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip perf/core
sha1: ceb9e77324fa661b1001a0ae66f061b5fcb4e4e6
---
Changes in v4:
- converted perfmon_capable() into an inline function
- made perf_events kprobes, uprobes, hw breakpoints and namespaces data available
to CAP_SYS_PERFMON privileged processes
- applied perfmon_capable() to drivers/perf and drivers/oprofile
- extended __cmd_ftrace() with support of CAP_SYS_PERFMON
Changes in v3:
- implemented perfmon_capable() macros aggregating required capabilities checks
Changes in v2:
- made perf_events trace points available to CAP_SYS_PERFMON privileged processes
- made perf_event_paranoid_check() treat CAP_SYS_PERFMON equally to CAP_SYS_ADMIN
- applied CAP_SYS_PERFMON to i915_perf, bpf_trace, powerpc and parisc system
performance monitoring and observability related subsystems
---
Alexey Budankov (9):
capabilities: introduce CAP_SYS_PERFMON to kernel and user space
perf/core: open access for CAP_SYS_PERFMON privileged process
perf tool: extend Perf tool with CAP_SYS_PERFMON capability support
drm/i915/perf: open access for CAP_SYS_PERFMON privileged process
trace/bpf_trace: open access for CAP_SYS_PERFMON privileged process
powerpc/perf: open access for CAP_SYS_PERFMON privileged process
parisc/perf: open access for CAP_SYS_PERFMON privileged process
drivers/perf: open access for CAP_SYS_PERFMON privileged process
drivers/oprofile: open access for CAP_SYS_PERFMON privileged process
arch/parisc/kernel/perf.c | 2 +-
arch/powerpc/perf/imc-pmu.c | 4 ++--
drivers/gpu/drm/i915/i915_perf.c | 13 ++++++-------
drivers/oprofile/event_buffer.c | 2 +-
drivers/perf/arm_spe_pmu.c | 4 ++--
include/linux/capability.h | 4 ++++
include/linux/perf_event.h | 6 +++---
include/uapi/linux/capability.h | 8 +++++++-
kernel/events/core.c | 6 +++---
kernel/trace/bpf_trace.c | 2 +-
security/selinux/include/classmap.h | 4 ++--
tools/perf/builtin-ftrace.c | 5 +++--
tools/perf/design.txt | 3 ++-
tools/perf/util/cap.h | 4 ++++
tools/perf/util/evsel.c | 10 +++++-----
tools/perf/util/util.c | 1 +
16 files changed, 47 insertions(+), 31 deletions(-)
---
Testing and validation (Intel Skylake, 8 cores, Fedora 29, 5.4.0-rc8+, x86_64):
libcap library [3], [4] and Perf tool can be used to apply CAP_SYS_PERFMON
capability for secure system performance monitoring and observability beyond the
scope permitted by the system wide perf_event_paranoid kernel setting [5] and
below are the steps for evaluation:
- 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]
# 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
---
[1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
[2] http://man7.org/linux/man-pages/man7/capabilities.7.html
[3] http://man7.org/linux/man-pages/man8/setcap.8.html
[4] https://git.kernel.org/pub/scm/libs/libcap/libcap.git
[5] http://man7.org/linux/man-pages/man2/perf_event_open.2.html
[6] https://sites.google.com/site/fullycapable/, posix_1003.1e-990310.pdf
--
2.20.1
Introduce CAP_SYS_PERFMON capability devoted to secure system performance
monitoring and observability operations so that CAP_SYS_PERFMON would
assist CAP_SYS_ADMIN capability in its governing role for perf_events,
i915_perf and other subsystems of the kernel.
CAP_SYS_PERFMON intends to harden system security and integrity during
system performance monitoring and observability operations by decreasing
attack surface that is available to CAP_SYS_ADMIN privileged processes.
CAP_SYS_PERFMON intends to take over CAP_SYS_ADMIN credentials related
to system performance monitoring and observability operations and balance
amount of CAP_SYS_ADMIN credentials in accordance with the recommendations
provided in the man page for CAP_SYS_ADMIN [1]: "Note: this capability
is overloaded; see Notes to kernel developers, below."
[1] http://man7.org/linux/man-pages/man7/capabilities.7.html
Signed-off-by: Alexey Budankov <redacted>
---
include/linux/capability.h | 4 ++++
include/uapi/linux/capability.h | 8 +++++++-
security/selinux/include/classmap.h | 4 ++--
3 files changed, 13 insertions(+), 3 deletions(-)
@@ -251,6 +251,10 @@ extern bool privileged_wrt_inode_uidgid(struct user_namespace *ns, const structexternboolcapable_wrt_inode_uidgid(conststructinode*inode,intcap);externboolfile_ns_capable(conststructfile*file,structuser_namespace*ns,intcap);externboolptracer_capable(structtask_struct*tsk,structuser_namespace*ns);+staticinlineboolperfmon_capable(void)+{+returncapable(CAP_SYS_PERFMON)||capable(CAP_SYS_ADMIN);+}/* audit system wants to get cap info from files as well */externintget_vfs_caps_from_disk(conststructdentry*dentry,structcpu_vfs_cap_data*cpu_caps);
Open access to perf_events monitoring for CAP_SYS_PERFMON privileged
processes. For backward compatibility reasons access to perf_events
subsystem remains open for CAP_SYS_ADMIN privileged processes but
CAP_SYS_ADMIN usage for secure perf_events monitoring is discouraged
with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
include/linux/perf_event.h | 6 +++---
kernel/events/core.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
@@ -284,10 +284,11 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int argc, const char **argv).events=POLLIN,};-if(!perf_cap__capable(CAP_SYS_ADMIN)){+if(!(perf_cap__capable(CAP_SYS_PERFMON)||+perf_cap__capable(CAP_SYS_ADMIN))){pr_err("ftrace only works for %s!\n",#ifdef HAVE_LIBCAP_SUPPORT-"users with the SYS_ADMIN capability"+"users with the CAP_SYS_PERFMON or CAP_SYS_ADMIN capability"#else"root"#endif
@@ -258,7 +258,8 @@ gets schedule to. Per task counters can be created by any user, for their own tasks. A 'pid == -1' and 'cpu == x' counter is a per CPU counter that counts-all events on CPU-x. Per CPU counters need CAP_SYS_ADMIN privilege.+all events on CPU-x. Per CPU counters need CAP_SYS_PERFMON or+CAP_SYS_ADMIN privilege. The 'flags' parameter is currently unused and must be zero.
@@ -2468,14 +2468,14 @@ int perf_evsel__open_strerror(struct evsel *evsel, struct target *target,"You may not have permission to collect %sstats.\n\n""Consider tweaking /proc/sys/kernel/perf_event_paranoid,\n""which controls use of the performance events system by\n"-"unprivileged users (without CAP_SYS_ADMIN).\n\n"+"unprivileged users (without CAP_SYS_PERFMON or CAP_SYS_ADMIN).\n\n""The current value is %d:\n\n"" -1: Allow use of (almost) all events by all users\n"" Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK\n"-">= 0: Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN\n"-" Disallow raw tracepoint access by users without CAP_SYS_ADMIN\n"-">= 1: Disallow CPU event access by users without CAP_SYS_ADMIN\n"-">= 2: Disallow kernel profiling by users without CAP_SYS_ADMIN\n\n"+">= 0: Disallow ftrace function tracepoint by users without CAP_SYS_PERFMON or CAP_SYS_ADMIN\n"+" Disallow raw tracepoint access by users without CAP_SYS_PERFMON or CAP_SYS_ADMIN\n"+">= 1: Disallow CPU event access by users without CAP_SYS_PERFMON or CAP_SYS_ADMIN\n"+">= 2: Disallow kernel profiling by users without CAP_SYS_PERFMON or CAP_SYS_ADMIN\n\n""To make this setting permanent, edit /etc/sysctl.conf too, e.g.:\n\n"" kernel.perf_event_paranoid = -1\n",target->system_wide?"system-wide ":"",
Open access to i915_perf monitoring for CAP_SYS_PERFMON privileged
processes. For backward compatibility reasons access to i915_perf
subsystem remains open for CAP_SYS_ADMIN privileged processes but
CAP_SYS_ADMIN usage for secure i915_perf monitoring is discouraged
with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
drivers/gpu/drm/i915/i915_perf.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
@@ -2748,10 +2748,10 @@ i915_perf_open_ioctl_locked(struct drm_i915_private *dev_priv,/* Similar to perf's kernel.perf_paranoid_cpu sysctl option*wecheckadev.i915.perf_stream_paranoidsysctloption*todetermineifit'soktoaccesssystemwideOAcounters-*withoutCAP_SYS_ADMINprivileges.+*withoutCAP_SYS_PERFMONorCAP_SYS_ADMINprivileges.*/if(privileged_op&&-i915_perf_stream_paranoid&&!capable(CAP_SYS_ADMIN)){+i915_perf_stream_paranoid&&!perfmon_capable()){DRM_DEBUG("Insufficient privileges to open system-wide i915 perf stream\n");ret=-EACCES;gotoerr_ctx;
@@ -2939,9 +2939,8 @@ static int read_properties_unlocked(struct drm_i915_private *dev_priv,}elseoa_freq_hz=0;-if(oa_freq_hz>i915_oa_max_sample_rate&&-!capable(CAP_SYS_ADMIN)){-DRM_DEBUG("OA exponent would exceed the max sampling frequency (sysctl dev.i915.oa_max_sample_rate) %uHz without root privileges\n",+if(oa_freq_hz>i915_oa_max_sample_rate&&!perfmon_capable()){+DRM_DEBUG("OA exponent would exceed the max sampling frequency (sysctl dev.i915.oa_max_sample_rate) %uHz without CAP_SYS_PERFMON or CAP_SYS_ADMIN privileges\n",i915_oa_max_sample_rate);return-EACCES;}
@@ -3328,7 +3327,7 @@ int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,return-EINVAL;}-if(i915_perf_stream_paranoid&&!capable(CAP_SYS_ADMIN)){+if(i915_perf_stream_paranoid&&!perfmon_capable()){DRM_DEBUG("Insufficient privileges to add i915 OA config\n");return-EACCES;}
@@ -3474,7 +3473,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,return-ENOTSUPP;}-if(i915_perf_stream_paranoid&&!capable(CAP_SYS_ADMIN)){+if(i915_perf_stream_paranoid&&!perfmon_capable()){DRM_DEBUG("Insufficient privileges to remove i915 OA config\n");return-EACCES;}
Open access to bpf_trace monitoring for CAP_SYS_PERFMON privileged
processes. For backward compatibility reasons access to bpf_trace
monitoring remains open for CAP_SYS_ADMIN privileged processes but
CAP_SYS_ADMIN usage for secure bpf_trace monitoring is discouraged
with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
kernel/trace/bpf_trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Open access to monitoring for CAP_SYS_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains open
for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
monitoring is discouraged with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
arch/powerpc/perf/imc-pmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -898,7 +898,7 @@ static int thread_imc_event_init(struct perf_event *event)if(event->attr.type!=event->pmu->type)return-ENOENT;-if(!capable(CAP_SYS_ADMIN))+if(!perfmon_capable())return-EACCES;/* Sampling not supported */
@@ -1307,7 +1307,7 @@ static int trace_imc_event_init(struct perf_event *event)if(event->attr.type!=event->pmu->type)return-ENOENT;-if(!capable(CAP_SYS_ADMIN))+if(!perfmon_capable())return-EACCES;/* Return if this is a couting event */
Open access to monitoring for CAP_SYS_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains open
for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
monitoring is discouraged with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
arch/parisc/kernel/perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Open access to monitoring for CAP_SYS_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains open
for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
monitoring is discouraged with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
drivers/perf/arm_spe_pmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Open access to monitoring for CAP_SYS_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains open
for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
monitoring is discouraged with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
drivers/oprofile/event_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Stephen Smalley <hidden> Date: 2019-12-18 19:56:46
On 12/18/19 4:24 AM, Alexey Budankov wrote:
Introduce CAP_SYS_PERFMON capability devoted to secure system performance
monitoring and observability operations so that CAP_SYS_PERFMON would
assist CAP_SYS_ADMIN capability in its governing role for perf_events,
i915_perf and other subsystems of the kernel.
CAP_SYS_PERFMON intends to harden system security and integrity during
system performance monitoring and observability operations by decreasing
attack surface that is available to CAP_SYS_ADMIN privileged processes.
CAP_SYS_PERFMON intends to take over CAP_SYS_ADMIN credentials related
to system performance monitoring and observability operations and balance
amount of CAP_SYS_ADMIN credentials in accordance with the recommendations
provided in the man page for CAP_SYS_ADMIN [1]: "Note: this capability
is overloaded; see Notes to kernel developers, below."
[1] http://man7.org/linux/man-pages/man7/capabilities.7.html
Signed-off-by: Alexey Budankov <redacted>
Acked-by: Stephen Smalley <redacted>
Note for selinux developers: we will need to update the
selinux-testsuite tests for perf_event when/if this change lands upstream.
@@ -251,6 +251,10 @@ extern bool privileged_wrt_inode_uidgid(struct user_namespace *ns, const structexternboolcapable_wrt_inode_uidgid(conststructinode*inode,intcap);externboolfile_ns_capable(conststructfile*file,structuser_namespace*ns,intcap);externboolptracer_capable(structtask_struct*tsk,structuser_namespace*ns);+staticinlineboolperfmon_capable(void)+{+returncapable(CAP_SYS_PERFMON)||capable(CAP_SYS_ADMIN);+}/* audit system wants to get cap info from files as well */externintget_vfs_caps_from_disk(conststructdentry*dentry,structcpu_vfs_cap_data*cpu_caps);
Open access to i915_perf monitoring for CAP_SYS_PERFMON privileged
processes. For backward compatibility reasons access to i915_perf
subsystem remains open for CAP_SYS_ADMIN privileged processes but
CAP_SYS_ADMIN usage for secure i915_perf monitoring is discouraged
with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
@@ -2748,10 +2748,10 @@ i915_perf_open_ioctl_locked(struct drm_i915_private *dev_priv,/* Similar to perf's kernel.perf_paranoid_cpu sysctl option*wecheckadev.i915.perf_stream_paranoidsysctloption*todetermineifit'soktoaccesssystemwideOAcounters-*withoutCAP_SYS_ADMINprivileges.+*withoutCAP_SYS_PERFMONorCAP_SYS_ADMINprivileges.*/if(privileged_op&&-i915_perf_stream_paranoid&&!capable(CAP_SYS_ADMIN)){+i915_perf_stream_paranoid&&!perfmon_capable()){DRM_DEBUG("Insufficient privileges to open system-wide i915 perf stream\n");ret=-EACCES;gotoerr_ctx;
@@ -2939,9 +2939,8 @@ static int read_properties_unlocked(struct drm_i915_private *dev_priv,}elseoa_freq_hz=0;-if(oa_freq_hz>i915_oa_max_sample_rate&&-!capable(CAP_SYS_ADMIN)){-DRM_DEBUG("OA exponent would exceed the max sampling frequency (sysctl dev.i915.oa_max_sample_rate) %uHz without root privileges\n",+if(oa_freq_hz>i915_oa_max_sample_rate&&!perfmon_capable()){+DRM_DEBUG("OA exponent would exceed the max sampling frequency (sysctl dev.i915.oa_max_sample_rate) %uHz without CAP_SYS_PERFMON or CAP_SYS_ADMIN privileges\n",i915_oa_max_sample_rate);return-EACCES;}
@@ -3328,7 +3327,7 @@ int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,return-EINVAL;}-if(i915_perf_stream_paranoid&&!capable(CAP_SYS_ADMIN)){+if(i915_perf_stream_paranoid&&!perfmon_capable()){DRM_DEBUG("Insufficient privileges to add i915 OA config\n");return-EACCES;}
@@ -3474,7 +3473,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,return-ENOTSUPP;}-if(i915_perf_stream_paranoid&&!capable(CAP_SYS_ADMIN)){+if(i915_perf_stream_paranoid&&!perfmon_capable()){DRM_DEBUG("Insufficient privileges to remove i915 OA config\n");return-EACCES;}
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2019-12-28 03:53:55
On Wed, Dec 18, 2019 at 12:24:28PM +0300, Alexey Budankov wrote:
Introduce CAP_SYS_PERFMON capability devoted to secure system performance
monitoring and observability operations so that CAP_SYS_PERFMON would
assist CAP_SYS_ADMIN capability in its governing role for perf_events,
i915_perf and other subsystems of the kernel.
CAP_SYS_PERFMON intends to harden system security and integrity during
system performance monitoring and observability operations by decreasing
attack surface that is available to CAP_SYS_ADMIN privileged processes.
CAP_SYS_PERFMON intends to take over CAP_SYS_ADMIN credentials related
to system performance monitoring and observability operations and balance
amount of CAP_SYS_ADMIN credentials in accordance with the recommendations
provided in the man page for CAP_SYS_ADMIN [1]: "Note: this capability
is overloaded; see Notes to kernel developers, below."
[1] http://man7.org/linux/man-pages/man7/capabilities.7.html
Signed-off-by: Alexey Budankov <redacted>
From: Peter Zijlstra <peterz@infradead.org> Date: 2020-01-08 16:07:51
On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
quoted hunk
Open access to perf_events monitoring for CAP_SYS_PERFMON privileged
processes. For backward compatibility reasons access to perf_events
subsystem remains open for CAP_SYS_ADMIN privileged processes but
CAP_SYS_ADMIN usage for secure perf_events monitoring is discouraged
with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
include/linux/perf_event.h | 6 +++---
kernel/events/core.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
@@ -9056,7 +9056,7 @@ static int perf_kprobe_event_init(struct perf_event *event)if(event->attr.type!=perf_kprobe.type)return-ENOENT;-if(!capable(CAP_SYS_ADMIN))+if(!perfmon_capable())return-EACCES;/*
This one only allows attaching to already extant kprobes, right? It does
not allow creation of kprobes.
quoted hunk
@@ -9116,7 +9116,7 @@ static int perf_uprobe_event_init(struct perf_event *event) if (event->attr.type != perf_uprobe.type) return -ENOENT;- if (!capable(CAP_SYS_ADMIN))+ if (!perfmon_capable()) return -EACCES; /*
Idem, I presume.
quoted hunk
@@ -11157,7 +11157,7 @@ SYSCALL_DEFINE5(perf_event_open, } if (attr.namespaces) {- if (!capable(CAP_SYS_ADMIN))+ if (!perfmon_capable()) return -EACCES; }
And given we basically make the entire kernel observable with this CAP,
busting namespaces shoulnd't be a problem either.
So yeah, I suppose that works.
On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
quoted
Open access to perf_events monitoring for CAP_SYS_PERFMON privileged
processes. For backward compatibility reasons access to perf_events
subsystem remains open for CAP_SYS_ADMIN privileged processes but
CAP_SYS_ADMIN usage for secure perf_events monitoring is discouraged
with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
include/linux/perf_event.h | 6 +++---
kernel/events/core.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
@@ -9056,7 +9056,7 @@ static int perf_kprobe_event_init(struct perf_event *event)if(event->attr.type!=perf_kprobe.type)return-ENOENT;-if(!capable(CAP_SYS_ADMIN))+if(!perfmon_capable())return-EACCES;/*
This one only allows attaching to already extant kprobes, right? It does
not allow creation of kprobes.
This unblocks creation of local trace kprobes and uprobes by CAP_SYS_PERFMON
privileged process, exactly the same as for CAP_SYS_ADMIN privileged process.
quoted
@@ -9116,7 +9116,7 @@ static int perf_uprobe_event_init(struct perf_event *event) if (event->attr.type != perf_uprobe.type) return -ENOENT;- if (!capable(CAP_SYS_ADMIN))+ if (!perfmon_capable()) return -EACCES; /*
Idem, I presume.
quoted
@@ -11157,7 +11157,7 @@ SYSCALL_DEFINE5(perf_event_open, } if (attr.namespaces) {- if (!capable(CAP_SYS_ADMIN))+ if (!perfmon_capable()) return -EACCES; }
And given we basically make the entire kernel observable with this CAP,
busting namespaces shoulnd't be a problem either.
So yeah, I suppose that works.
@@ -9056,7 +9056,7 @@ static int perf_kprobe_event_init(struct perf_event *event)if(event->attr.type!=perf_kprobe.type)return-ENOENT;-if(!capable(CAP_SYS_ADMIN))+if(!perfmon_capable())return-EACCES;/*
This one only allows attaching to already extant kprobes, right? It does
not allow creation of kprobes.
This unblocks creation of local trace kprobes and uprobes by CAP_SYS_PERFMON
privileged process, exactly the same as for CAP_SYS_ADMIN privileged process.
I've no idea what you just said; it's just words.
Again, this only allows attaching to previously created kprobes, it does
not allow creating kprobes, right?
That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.
As might be clear; I don't actually know what the user-ABI is for
creating kprobes.
@@ -9056,7 +9056,7 @@ static int perf_kprobe_event_init(struct perf_event *event)if(event->attr.type!=perf_kprobe.type)return-ENOENT;-if(!capable(CAP_SYS_ADMIN))+if(!perfmon_capable())return-EACCES;/*
This one only allows attaching to already extant kprobes, right? It does
not allow creation of kprobes.
This unblocks creation of local trace kprobes and uprobes by CAP_SYS_PERFMON
privileged process, exactly the same as for CAP_SYS_ADMIN privileged process.
I've no idea what you just said; it's just words.
Again, this only allows attaching to previously created kprobes, it does
not allow creating kprobes, right?
That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.
As might be clear; I don't actually know what the user-ABI is for
creating kprobes.
There are 2 ABIs nowadays, ftrace and ebpf. perf-probe uses ftrace interface to
define new kprobe events, and those events are treated as completely same as
tracepoint events. On the other hand, ebpf tries to define new probe event
via perf_event interface. Above one is that interface. IOW, it creates new kprobe.
Thank you,
--
Masami Hiramatsu [off-list ref]
@@ -9056,7 +9056,7 @@ static int perf_kprobe_event_init(struct perf_event *event)if(event->attr.type!=perf_kprobe.type)return-ENOENT;-if(!capable(CAP_SYS_ADMIN))+if(!perfmon_capable())return-EACCES;/*
This one only allows attaching to already extant kprobes, right? It does
not allow creation of kprobes.
This unblocks creation of local trace kprobes and uprobes by CAP_SYS_PERFMON
privileged process, exactly the same as for CAP_SYS_ADMIN privileged process.
I've no idea what you just said; it's just words.
Again, this only allows attaching to previously created kprobes, it does
not allow creating kprobes, right?
Not really, this allows creating a kprobe using perf_event_open syscall that
associates file descriptor with the kprobe [1].
Lifetime of that kprobe is equal to the lifetime of the file descriptor and
the kprobe is not visible in tracefs: /sys/kernel/debug/tracing/kprobe_events
That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.
As might be clear; I don't actually know what the user-ABI is for
creating kprobes.
From: Arnaldo Carvalho de Melo <acme@kernel.org> Date: 2020-01-10 16:45:42
Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu:
On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra [off-list ref] wrote:
quoted
Again, this only allows attaching to previously created kprobes, it does
not allow creating kprobes, right?
quoted
That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.
quoted
As might be clear; I don't actually know what the user-ABI is for
creating kprobes.
There are 2 ABIs nowadays, ftrace and ebpf. perf-probe uses ftrace interface to
define new kprobe events, and those events are treated as completely same as
tracepoint events. On the other hand, ebpf tries to define new probe event
via perf_event interface. Above one is that interface. IOW, it creates new kprobe.
Masami, any plans to make 'perf probe' use the perf_event_open()
interface for creating kprobes/uprobes?
- Arnaldo
@@ -9056,7 +9056,7 @@ static int perf_kprobe_event_init(struct perf_event *event)if(event->attr.type!=perf_kprobe.type)return-ENOENT;-if(!capable(CAP_SYS_ADMIN))+if(!perfmon_capable())return-EACCES;/*
This one only allows attaching to already extant kprobes, right? It does
not allow creation of kprobes.
This unblocks creation of local trace kprobes and uprobes by CAP_SYS_PERFMON
privileged process, exactly the same as for CAP_SYS_ADMIN privileged process.
I've no idea what you just said; it's just words.
Again, this only allows attaching to previously created kprobes, it does
not allow creating kprobes, right?
Not really, this allows creating a kprobe using perf_event_open syscall that
associates file descriptor with the kprobe [1].
Lifetime of that kprobe is equal to the lifetime of the file descriptor and
the kprobe is not visible in tracefs: /sys/kernel/debug/tracing/kprobe_events
That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.
As might be clear; I don't actually know what the user-ABI is for
creating kprobes.
On Fri, 10 Jan 2020 13:45:31 -0300
Arnaldo Carvalho de Melo [off-list ref] wrote:
Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu:
quoted
On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra [off-list ref] wrote:
quoted
Again, this only allows attaching to previously created kprobes, it does
not allow creating kprobes, right?
quoted
quoted
That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.
quoted
quoted
As might be clear; I don't actually know what the user-ABI is for
creating kprobes.
quoted
There are 2 ABIs nowadays, ftrace and ebpf. perf-probe uses ftrace interface to
define new kprobe events, and those events are treated as completely same as
tracepoint events. On the other hand, ebpf tries to define new probe event
via perf_event interface. Above one is that interface. IOW, it creates new kprobe.
Masami, any plans to make 'perf probe' use the perf_event_open()
interface for creating kprobes/uprobes?
Would you mean perf probe to switch to perf_event_open()?
No, perf probe is for setting up the ftrace probe events. I think we can add an
option to use perf_event_open(). But current kprobe creation from perf_event_open()
is separated from ftrace by design.
I think the reason why ebpf uses perf_event_open() interface is to avoid conflict
with ftrace users. Those probes are temporally used by ebpf, but if it is appeared on
ftrace, it is easy to be used by ftrace. In that case, it can not be removed when
the ebpf exits.
Thank you,
--
Masami Hiramatsu [off-list ref]
On Jan 10, 2020, at 3:47 PM, Masami Hiramatsu [off-list ref] wrote:
On Fri, 10 Jan 2020 13:45:31 -0300
Arnaldo Carvalho de Melo [off-list ref] wrote:
quoted
Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu:
quoted
On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra [off-list ref] wrote:
quoted
Again, this only allows attaching to previously created kprobes, it does
not allow creating kprobes, right?
quoted
quoted
That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.
quoted
quoted
As might be clear; I don't actually know what the user-ABI is for
creating kprobes.
quoted
There are 2 ABIs nowadays, ftrace and ebpf. perf-probe uses ftrace interface to
define new kprobe events, and those events are treated as completely same as
tracepoint events. On the other hand, ebpf tries to define new probe event
via perf_event interface. Above one is that interface. IOW, it creates new kprobe.
Masami, any plans to make 'perf probe' use the perf_event_open()
interface for creating kprobes/uprobes?
Would you mean perf probe to switch to perf_event_open()?
No, perf probe is for setting up the ftrace probe events. I think we can add an
option to use perf_event_open(). But current kprobe creation from perf_event_open()
is separated from ftrace by design.
I guess we can extend event parser to understand kprobe directly. Instead of
perf probe kernel_func
perf stat/record -e probe:kernel_func ...
We can just do
perf stat/record -e kprobe:kernel_func ...
Thanks,
Song
On Jan 10, 2020, at 3:47 PM, Masami Hiramatsu [off-list ref]
wrote:
quoted
On Fri, 10 Jan 2020 13:45:31 -0300
Arnaldo Carvalho de Melo [off-list ref] wrote:
quoted
Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu:
quoted
On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra
[off-list ref] wrote:
quoted
quoted
quoted
quoted
Again, this only allows attaching to previously created kprobes,
it does
quoted
quoted
quoted
quoted
not allow creating kprobes, right?
quoted
quoted
That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.
quoted
quoted
As might be clear; I don't actually know what the user-ABI is for
creating kprobes.
quoted
There are 2 ABIs nowadays, ftrace and ebpf. perf-probe uses ftrace
interface to
quoted
quoted
quoted
define new kprobe events, and those events are treated as
completely same as
quoted
quoted
quoted
tracepoint events. On the other hand, ebpf tries to define new
probe event
quoted
quoted
quoted
via perf_event interface. Above one is that interface. IOW, it
creates new kprobe.
quoted
quoted
Masami, any plans to make 'perf probe' use the perf_event_open()
interface for creating kprobes/uprobes?
Would you mean perf probe to switch to perf_event_open()?
No, perf probe is for setting up the ftrace probe events. I think we
can add an
quoted
option to use perf_event_open(). But current kprobe creation from
perf_event_open()
quoted
is separated from ftrace by design.
I guess we can extend event parser to understand kprobe directly.
Instead of
perf probe kernel_func
perf stat/record -e probe:kernel_func ...
We can just do
perf stat/record -e kprobe:kernel_func ...
You took the words from my mouth, exactly, that is a perfect use case, an alternative to the 'perf probe' one of making a disabled event that then gets activated via record/stat/trace, in many cases it's better, removes the explicit probe setup case.
Regards,
- Arnaldo
On Jan 10, 2020, at 3:47 PM, Masami Hiramatsu [off-list ref]
wrote:
quoted
On Fri, 10 Jan 2020 13:45:31 -0300
Arnaldo Carvalho de Melo [off-list ref] wrote:
quoted
Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu:
quoted
On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra
[off-list ref] wrote:
quoted
quoted
quoted
quoted
Again, this only allows attaching to previously created kprobes,
it does
quoted
quoted
quoted
quoted
not allow creating kprobes, right?
quoted
quoted
That is; I don't think CAP_SYS_PERFMON should be allowed to create
kprobes.
quoted
quoted
As might be clear; I don't actually know what the user-ABI is for
creating kprobes.
quoted
There are 2 ABIs nowadays, ftrace and ebpf. perf-probe uses ftrace
interface to
quoted
quoted
quoted
define new kprobe events, and those events are treated as
completely same as
quoted
quoted
quoted
tracepoint events. On the other hand, ebpf tries to define new
probe event
quoted
quoted
quoted
via perf_event interface. Above one is that interface. IOW, it
creates new kprobe.
quoted
quoted
Masami, any plans to make 'perf probe' use the perf_event_open()
interface for creating kprobes/uprobes?
Would you mean perf probe to switch to perf_event_open()?
No, perf probe is for setting up the ftrace probe events. I think we
can add an
quoted
option to use perf_event_open(). But current kprobe creation from
perf_event_open()
quoted
is separated from ftrace by design.
I guess we can extend event parser to understand kprobe directly.
Instead of
perf probe kernel_func
perf stat/record -e probe:kernel_func ...
We can just do
perf stat/record -e kprobe:kernel_func ...
You took the words from my mouth, exactly, that is a perfect use case, an alternative to the 'perf probe' one of making a disabled event that then gets activated via record/stat/trace, in many cases it's better, removes the explicit probe setup case.
Ah, I got it. If the perf event parser just kicks perf's kprobe creation
interface, it will be easy. In that case, there should be following differences.
- perf * -e "kprobe":kernel_func will put a local (hidden) kprobe
events. So ftrace user can not access it.
- perf * -e "kprobe":kernel_func may not support inline/function-body
nor trace local variables etc.
Hm, if we support inline function via -e "kprobe" interface, we have to
expand perf_event_open() to support multi-probe event.
Thanks,
On Dec 18, 2019, at 1:24 AM, Alexey Budankov [off-list ref] wrote:
Introduce CAP_SYS_PERFMON capability devoted to secure system performance
monitoring and observability operations so that CAP_SYS_PERFMON would
assist CAP_SYS_ADMIN capability in its governing role for perf_events,
i915_perf and other subsystems of the kernel.
CAP_SYS_PERFMON intends to harden system security and integrity during
system performance monitoring and observability operations by decreasing
attack surface that is available to CAP_SYS_ADMIN privileged processes.
CAP_SYS_PERFMON intends to take over CAP_SYS_ADMIN credentials related
to system performance monitoring and observability operations and balance
amount of CAP_SYS_ADMIN credentials in accordance with the recommendations
provided in the man page for CAP_SYS_ADMIN [1]: "Note: this capability
is overloaded; see Notes to kernel developers, below."
[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__man7.org_linux_man-2Dpages_man7_capabilities.7.html&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=dR8692q0_uaizy0jkrBJQM5k2hfm4CiFxYT8KaysFrg&m=L5qCuMRrTvYhyjR1rpgE9vEv4HppVlOXDIzKzoGL30c&s=FNJpET4buKFRuqktVHQphaY1qE7IsdFpU4iYwpCn4tY&e=
Signed-off-by: Alexey Budankov <redacted>
On Dec 18, 2019, at 1:28 AM, Alexey Budankov [off-list ref] wrote:
Open access to bpf_trace monitoring for CAP_SYS_PERFMON privileged
processes. For backward compatibility reasons access to bpf_trace
monitoring remains open for CAP_SYS_ADMIN privileged processes but
CAP_SYS_ADMIN usage for secure bpf_trace monitoring is discouraged
with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
u32 *ids, prog_cnt, ids_len;
int ret;
- if (!capable(CAP_SYS_ADMIN))
+ if (!perfmon_capable())
return -EPERM;
if (event->attr.type != PERF_TYPE_TRACEPOINT)
return -EINVAL;
I guess we need to fix this check for kprobe/uprobe created with
perf_event_open()...
Thanks,
Song
From: Will Deacon <will@kernel.org> Date: 2020-01-17 10:52:11
On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote:
quoted hunk
Open access to monitoring for CAP_SYS_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains open
for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
monitoring is discouraged with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
drivers/perf/arm_spe_pmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event)return-EOPNOTSUPP;reg=arm_spe_event_to_pmscr(event);-if(!capable(CAP_SYS_ADMIN)&&+if(!perfmon_capable()&&(reg&(BIT(SYS_PMSCR_EL1_PA_SHIFT)|BIT(SYS_PMSCR_EL1_CX_SHIFT)|BIT(SYS_PMSCR_EL1_PCT_SHIFT))))
Acked-by: Will Deacon <will@kernel.org>
Worth noting that this allows profiling of *physical* addresses used by
memory access instructions and so probably has some security implications
beyond the usual "but perf is buggy" line of reasoning.
Will
On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote:
quoted
Open access to monitoring for CAP_SYS_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains open
for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
monitoring is discouraged with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>
---
drivers/perf/arm_spe_pmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event)return-EOPNOTSUPP;reg=arm_spe_event_to_pmscr(event);-if(!capable(CAP_SYS_ADMIN)&&+if(!perfmon_capable()&&(reg&(BIT(SYS_PMSCR_EL1_PA_SHIFT)|BIT(SYS_PMSCR_EL1_CX_SHIFT)|BIT(SYS_PMSCR_EL1_PCT_SHIFT))))
Acked-by: Will Deacon <will@kernel.org>
Worth noting that this allows profiling of *physical* addresses used by
memory access instructions and so probably has some security implications
beyond the usual "but perf is buggy" line of reasoning.
Good to know. Thank you!
The data on physical addresses used by memory access instructions can already be
provided under CAP_SYS_ADMIN privileges [1] thus, I suppose, any implications you
have mentioned are already in place. I believe providing the data under CAP_PERFMON
alone without the rest of CAP_SYS_ADMIN credentials decreases chances to misuse the
data for harm and makes the monitoring more secure.
~Alexey
[1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
Open access to monitoring for CAP_SYS_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains open
for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
monitoring is discouraged with respect to CAP_SYS_PERFMON capability.
Signed-off-by: Alexey Budankov <redacted>