Hi Michael, On 23.08.2020 20:28, Michael Kerrisk (man-pages) wrote: > Hello Alexey, > > Could you look at the question below and update the patch. > > On 2/17/20 9:18 AM, Alexey Budankov wrote: >> >> Extend perf_event_open 2 man page with the information about >> CAP_PERFMON capability designed to secure performance monitoring >> and observability operation in a system according to the principle >> of least privilege [1] (POSIX IEEE 1003.1e, 2.2.2.39). >> >> [1] https://sites.google.com/site/fullycapable/, posix_1003.1e-990310.pdf >> >> Signed-off-by: Alexey Budankov <alexey.budankov@xxxxxxxxxxxxxxx> >> --- >> man2/perf_event_open.2 | 27 +++++++++++++++++++++++++++ >> 1 file changed, 27 insertions(+) >> >> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2 >> index 89d267c02..e9aab2ca1 100644 >> --- a/man2/perf_event_open.2 >> +++ b/man2/perf_event_open.2 >> @@ -98,6 +98,8 @@ when running on the specified CPU. >> .BR "pid == \-1" " and " "cpu >= 0" >> This measures all processes/threads on the specified CPU. >> This requires >> +.B CAP_PERFMON >> +or >> .B CAP_SYS_ADMIN >> capability or a >> .I /proc/sys/kernel/perf_event_paranoid >> @@ -2920,6 +2922,8 @@ to hold the result. >> This allows attaching a Berkeley Packet Filter (BPF) >> program to an existing kprobe tracepoint event. >> You need >> +.B CAP_PERFMON >> +or >> .B CAP_SYS_ADMIN >> privileges to use this ioctl. >> .IP >> @@ -2962,6 +2966,8 @@ have multiple events attached to a tracepoint. >> Querying this value on one tracepoint event returns the id >> of all BPF programs in all events attached to the tracepoint. >> You need >> +.B CAP_PERFMON >> +or >> .B CAP_SYS_ADMIN >> privileges to use this ioctl. >> .IP >> @@ -3170,6 +3176,8 @@ it was expecting. >> .TP >> .B EACCES >> Returned when the requested event requires >> +.B CAP_PERFMON >> +or >> .B CAP_SYS_ADMIN >> permissions (or a more permissive perf_event paranoid setting). >> Some common cases where an unprivileged process >> @@ -3291,6 +3299,8 @@ setting is specified. >> It can also happen, as with >> .BR EACCES , >> when the requested event requires >> +.B CAP_PERFMON >> +or >> .B CAP_SYS_ADMIN >> permissions (or a more permissive perf_event paranoid setting). >> This includes setting a breakpoint on a kernel address, >> @@ -3321,6 +3331,23 @@ The official way of knowing if >> support is enabled is checking >> for the existence of the file >> .IR /proc/sys/kernel/perf_event_paranoid . >> +.PP >> +.B CAP_PERFMON >> +capability (since Linux X.Y) provides secure approach to > > What's the version? It's since Linux 5.8 . > >> +performance monitoring and observability operations in a system >> +according to the principal of least privilege (POSIX IEEE 1003.1e). >> +Accessing system performance monitoring and observability operations >> +using >> +.B CAP_PERFMON >> +capability singly, without the rest of >> +.B CAP_SYS_ADMIN >> +credentials, excludes chances to misuse the credentials and makes > > I think that wording like "using CAP_PERFMON rather than the much > more powerful CAP_SYS_ADMIN..." Sounds good to me like this, or similar: "Accessing system performance monitoring and observability operations using CAP_PERFMON rather than the much more powerful CAP_SYS_ADMIN excludes chances to misuse credentials and makes operations more secure." > >> +the operations more secure. >> +.B CAP_SYS_ADMIN >> +usage for secure system performance monitoring and observability >> +is discouraged with respect to >> +.B CAP_PERFMON >> +capability. >> .SH BUGS >> The >> .B F_SETOWN_EX > > Thanks, > > Michael > Thanks, Alexei P.S. I am on vacations till 08/31. Please expect delay in response.
