kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
* [PATCH v1 0/3] admin-guide: extend perf-security with resource control, data categories and privileged users
@ 2019-02-01  7:23 Alexey Budankov
  2019-02-01  7:29 ` [PATCH v1 1/3] perf-security: document perf_events/Perf resource control Alexey Budankov
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Alexey Budankov @ 2019-02-01  7:23 UTC (permalink / raw)
  To: Jonatan Corbet, Kees Cook, Peter Zijlstra, Thomas Gleixner, Ingo Molnar
  Cc: Jann Horn, Arnaldo Carvalho de Melo, Jiri Olsa, Namhyung Kim,
	Alexander Shishkin, Mark Rutland, Andi Kleen, Tvrtko Ursulin,
	kernel-hardening, linux-doc, linux-kernel


The patch set extends the first version of perf-security.rst documentation
file [1], [2], [3] with the following topics:

1) perf_events/Perf resource limits and control management that describes
   RLIMIT_NOFILE and perf_event_mlock_kb settings for processes conducting
   performance monitoring;

2) categories of system and performance data that can be captured by
   perf_events/Perf with explicit designation of process sensitive data;

3) possible steps to create perf_event/Perf privileged users groups for 
   the current implementations of perf_events syscall API [4] and Perf tool;

---
Alexey Budankov (3):
  perf-security: document perf_events/Perf resource control
  perf-security: document collected perf_events/Perf data categories
  perf-security: document perf_events/Perf resource control

 Documentation/admin-guide/perf-security.rst | 111 +++++++++++++++++++-
 1 file changed, 109 insertions(+), 2 deletions(-)

---
[1] https://marc.info/?l=linux-kernel&m=153736008310781&w=2
[2] https://lkml.org/lkml/2018/5/21/156
[3] https://lkml.org/lkml/2018/11/27/604
[4] http://man7.org/linux/man-pages/man2/perf_event_open.2.html

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH v1 1/3] perf-security: document perf_events/Perf resource control
  2019-02-01  7:23 [PATCH v1 0/3] admin-guide: extend perf-security with resource control, data categories and privileged users Alexey Budankov
@ 2019-02-01  7:29 ` Alexey Budankov
  2019-02-06 23:58   ` Jonathan Corbet
  2019-02-01  7:30 ` [PATCH v1 2/3] perf-security: document collected perf_events/Perf data categories Alexey Budankov
  2019-02-01  7:30 ` [PATCH v1 3/3] perf-security: document perf_events/Perf resource control Alexey Budankov
  2 siblings, 1 reply; 8+ messages in thread
From: Alexey Budankov @ 2019-02-01  7:29 UTC (permalink / raw)
  To: Jonatan Corbet, Kees Cook, Peter Zijlstra, Thomas Gleixner, Ingo Molnar
  Cc: Jann Horn, Arnaldo Carvalho de Melo, Jiri Olsa, Namhyung Kim,
	Alexander Shishkin, Mark Rutland, Andi Kleen, Tvrtko Ursulin,
	kernel-hardening, linux-doc, linux-kernel


Extend perf-security.rst file with perf_events/Perf resource control
section describing RLIMIT_NOFILE and perf_event_mlock_kb settings for
performance monitoring user processes.

Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
---
 Documentation/admin-guide/perf-security.rst | 36 +++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
index f73ebfe9bfe2..ff6832191577 100644
--- a/Documentation/admin-guide/perf-security.rst
+++ b/Documentation/admin-guide/perf-security.rst
@@ -84,6 +84,40 @@ governed by perf_event_paranoid [2]_ setting:
      locking limit is imposed but ignored for unprivileged processes with
      CAP_IPC_LOCK capability.
 
+perf_events/Perf resource control
+---------------------------------
+
+perf_events system call API [2]_ allocates file descriptors for every configured
+PMU event. Open file descriptors are a per-process accountable *resource* governed
+by RLIMIT_NOFILE [11]_ limit (ulimit -n), which is usually derived from the login
+shell process. When configuring Perf collection for a long list of events on a
+large server system, this limit can be easily hit preventing required monitoring
+configuration. RLIMIT_NOFILE limit can be increased on per-user basis modifying
+content of limits.conf file [12]_ on some systems. Ordinary Perf sampling session
+(perf record) requires an amount of open perf_event file descriptors that is not
+less than a number of monitored events multiplied by a number of monitored CPUs.
+
+An amount of memory available to user processes for capturing performance monitoring
+data is governed by perf_event_mlock_kb [2]_ setting. This perf_event specific
+*resource* setting defines overall per-cpu limits of memory allowed for mapping
+by the user processes to execute performance monitoring. The setting essentially
+extends RLIMIT_MEMLOCK [11]_ limit but only for memory regions mapped specially
+for capturing monitored performance events and related data.
+
+For example, if a machine has eight cores and perf_event_mlock_kb limit is set
+to 516 KiB then a user process is provided with 516 KiB * 8 = 4128 KiB of memory
+above RLIMIT_MEMLOCK limit (ulimit -l) for perf_event mmap buffers. In particular
+this means that if the user wants to start two or more performance monitoring
+processes, it is required to manually distribute available 4128 KiB between the
+monitoring processes, for example, using --mmap-pages Perf record mode option.
+Otherwise, the first started performance monitoring process allocates all available
+4128 KiB and the other processes will fail to proceed due to the lack of memory.
+
+RLIMIT_MEMLOCK and perf_event_mlock_kb *resource* constraints are ignored for
+processes with CAP_IPC_LOCK capability. Thus, perf_events/Perf privileged users
+can be provided with memory above the constraints for perf_events/Perf performance
+monitoring purpose by providing the Perf executable with CAP_IPC_LOCK capability.
+
 Bibliography
 ------------
 
@@ -94,4 +128,6 @@ Bibliography
 .. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
 .. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
 .. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_
+.. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_
+.. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH v1 2/3] perf-security: document collected perf_events/Perf data categories
  2019-02-01  7:23 [PATCH v1 0/3] admin-guide: extend perf-security with resource control, data categories and privileged users Alexey Budankov
  2019-02-01  7:29 ` [PATCH v1 1/3] perf-security: document perf_events/Perf resource control Alexey Budankov
@ 2019-02-01  7:30 ` Alexey Budankov
  2019-02-01  7:30 ` [PATCH v1 3/3] perf-security: document perf_events/Perf resource control Alexey Budankov
  2 siblings, 0 replies; 8+ messages in thread
From: Alexey Budankov @ 2019-02-01  7:30 UTC (permalink / raw)
  To: Jonatan Corbet, Kees Cook, Peter Zijlstra, Thomas Gleixner, Ingo Molnar
  Cc: Jann Horn, Arnaldo Carvalho de Melo, Jiri Olsa, Namhyung Kim,
	Alexander Shishkin, Mark Rutland, Andi Kleen, Tvrtko Ursulin,
	kernel-hardening, linux-doc, linux-kernel


Document and categorize system and performance data into groups that
can be captured by perf_events/Perf and explicitly indicate the group
that can contain process sensitive data.

Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
---
 Documentation/admin-guide/perf-security.rst | 32 +++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
index ff6832191577..7da7fa459718 100644
--- a/Documentation/admin-guide/perf-security.rst
+++ b/Documentation/admin-guide/perf-security.rst
@@ -11,8 +11,34 @@ impose a considerable risk of leaking sensitive data accessed by monitored
 processes. The data leakage is possible both in scenarios of direct usage of
 perf_events system call API [2]_ and over data files generated by Perf tool user
 mode utility (Perf) [3]_ , [4]_ . The risk depends on the nature of data that
-perf_events performance monitoring units (PMU) [2]_ collect and expose for
-performance analysis. Having that said perf_events/Perf performance monitoring
+perf_events performance monitoring units (PMU) [2]_ and Perf collect and expose
+for performance analysis. Collected system and performance data may be split into
+several categories:
+
+1. System hardware and software configuration data, for example: a CPU model and
+   its cache configuration, an amount of available memory and its topology, used
+   kernel and Perf versions, performance monitoring setup including experiment
+   time, events configuration, Perf command line parameters, etc.
+
+2. User and kernel module paths and their load addresses with sizes, process and
+   thread names with their PIDs and TIDs, timestamps for captured hardware and
+   software events.
+
+3. Content of kernel software counters (e.g., for context switches, page faults,
+   CPU migrations), architectural hardware performance counters (PMC) [8]_ and
+   machine specific registers (MSR) [9]_ that provide execution metrics for
+   various monitored parts of the system (e.g., memory controller (IMC), interconnect
+   (QPI/UPI) or peripheral (PCIe) uncore counters) without direct attribution to any
+   execution context state.
+
+4. Content of architectural execution context registers (e.g., RIP, RSP, RBP on
+   x86_64), process user and kernel space memory addresses and data, content of
+   various architectural MSRs that capture data from this category.
+
+Data that belong to the fourth category can potentially contain sensitive process
+data. If PMUs in some monitoring modes capture values of execution context registers
+or data from process memory then access to such monitoring capabilities requires
+to be ordered and secured properly. So, perf_events/Perf performance monitoring
 is the subject for security access control management [5]_ .
 
 perf_events/Perf access control
@@ -128,6 +154,8 @@ Bibliography
 .. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
 .. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
 .. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_
+.. [8] `<https://en.wikipedia.org/wiki/Hardware_performance_counter>`_
+.. [9] `<https://en.wikipedia.org/wiki/Model-specific_register>`_
 .. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_
 .. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH v1 3/3] perf-security: document perf_events/Perf resource control
  2019-02-01  7:23 [PATCH v1 0/3] admin-guide: extend perf-security with resource control, data categories and privileged users Alexey Budankov
  2019-02-01  7:29 ` [PATCH v1 1/3] perf-security: document perf_events/Perf resource control Alexey Budankov
  2019-02-01  7:30 ` [PATCH v1 2/3] perf-security: document collected perf_events/Perf data categories Alexey Budankov
@ 2019-02-01  7:30 ` Alexey Budankov
  2019-02-07  0:01   ` Jonathan Corbet
  2 siblings, 1 reply; 8+ messages in thread
From: Alexey Budankov @ 2019-02-01  7:30 UTC (permalink / raw)
  To: Jonatan Corbet, Kees Cook, Peter Zijlstra, Thomas Gleixner, Ingo Molnar
  Cc: Jann Horn, Arnaldo Carvalho de Melo, Jiri Olsa, Namhyung Kim,
	Alexander Shishkin, Mark Rutland, Andi Kleen, Tvrtko Ursulin,
	kernel-hardening, linux-doc, linux-kernel


Elaborate on possible perf_event/Perf privileged users groups
and document steps about creating such groups.

Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
---
 Documentation/admin-guide/perf-security.rst | 43 +++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
index 7da7fa459718..fe90f8952be9 100644
--- a/Documentation/admin-guide/perf-security.rst
+++ b/Documentation/admin-guide/perf-security.rst
@@ -73,6 +73,48 @@ enable capturing of additional data required for later performance analysis of
 monitored processes or a system. For example, CAP_SYSLOG capability permits
 reading kernel space memory addresses from /proc/kallsyms file.
 
+perf_events/Perf privileged users
+---------------------------------
+
+Mechanisms of capabilities, privileged capability-dumb files [6]_ and file system
+ACLs [10]_ can be used to create a dedicated group of perf_events/Perf privileged
+users who are permitted to execute performance monitoring without *scope* limits.
+The following steps can be taken to create such a group of privileged Perf users.
+
+1. Create perf_users group of privileged Perf users, assign perf_users group to
+   Perf tool executable and limit *access* to the executable for other users in
+   the system:
+
+::
+
+   # groupadd perf_users
+   # ls -alhF
+   -rwxr-xr-x  2 root root  11M Oct 19 15:12 perf
+   # chgrp perf_users perf
+   # ls -alhF
+   -rwxr-xr-x  2 root perf_users  11M Oct 19 15:12 perf
+   # chmod o-rwx perf
+   # ls -alhF
+   -rwxr-x---  2 root perf_users  11M Oct 19 15:12 perf
+
+2. Assign required capabilities to the Perf tool executable file and enable
+   members of perf_users group with performance monitoring privileges [6]_ :
+
+::
+
+   # setcap "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
+   # setcap -v "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
+   perf: OK
+   # getcap perf
+   perf = cap_sys_ptrace,cap_sys_admin,cap_syslog+ep
+
+As a result, members of perf_users group are capable of conducting performance
+monitoring by using functionality of the configured Perf tool executable that,
+when executes, passes perf_events subsystem *scope* checks.
+
+This specific *access* control management is only available to superuser or root
+running processes with CAP_SETPCAP, CAP_SETFCAP [6]_ capabilities.
+
 perf_events/Perf unprivileged users
 -----------------------------------
 
@@ -156,6 +198,7 @@ Bibliography
 .. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_
 .. [8] `<https://en.wikipedia.org/wiki/Hardware_performance_counter>`_
 .. [9] `<https://en.wikipedia.org/wiki/Model-specific_register>`_
+.. [10] `<http://man7.org/linux/man-pages/man5/acl.5.html>`_
 .. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_
 .. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v1 1/3] perf-security: document perf_events/Perf resource control
  2019-02-01  7:29 ` [PATCH v1 1/3] perf-security: document perf_events/Perf resource control Alexey Budankov
@ 2019-02-06 23:58   ` Jonathan Corbet
  2019-02-07 13:14     ` Alexey Budankov
  0 siblings, 1 reply; 8+ messages in thread
From: Jonathan Corbet @ 2019-02-06 23:58 UTC (permalink / raw)
  To: Alexey Budankov
  Cc: Kees Cook, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
	Jann Horn, Arnaldo Carvalho de Melo, Jiri Olsa, Namhyung Kim,
	Alexander Shishkin, Mark Rutland, Andi Kleen, Tvrtko Ursulin,
	kernel-hardening, linux-doc, linux-kernel

On Fri, 1 Feb 2019 10:29:11 +0300
Alexey Budankov <alexey.budankov@linux.intel.com> wrote:

> Extend perf-security.rst file with perf_events/Perf resource control
> section describing RLIMIT_NOFILE and perf_event_mlock_kb settings for
> performance monitoring user processes.
> 
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>

Overall these patches seem reasonable, though I have some nits to pick.
I'm happy to apply them but wouldn't mind an ack from the perf camp.

Alexey, could you wrap your paragraphs at 72-75 columns?

> ---
>  Documentation/admin-guide/perf-security.rst | 36 +++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
> index f73ebfe9bfe2..ff6832191577 100644
> --- a/Documentation/admin-guide/perf-security.rst
> +++ b/Documentation/admin-guide/perf-security.rst
> @@ -84,6 +84,40 @@ governed by perf_event_paranoid [2]_ setting:
>       locking limit is imposed but ignored for unprivileged processes with
>       CAP_IPC_LOCK capability.
>  
> +perf_events/Perf resource control
> +---------------------------------
> +
> +perf_events system call API [2]_ allocates file descriptors for every configured

*The* perf_events system call API

> +PMU event. Open file descriptors are a per-process accountable *resource* governed
> +by RLIMIT_NOFILE [11]_ limit (ulimit -n), which is usually derived from the login

by *the* RLIMIT_NOFILE

> +shell process. When configuring Perf collection for a long list of events on a
> +large server system, this limit can be easily hit preventing required monitoring
> +configuration. RLIMIT_NOFILE limit can be increased on per-user basis modifying
> +content of limits.conf file [12]_ on some systems. Ordinary Perf sampling session

of *the* limits.conf file

Ordinarily, a Perf

> +(perf record) requires an amount of open perf_event file descriptors that is not
> +less than a number of monitored events multiplied by a number of monitored CPUs.
> +
> +An amount of memory available to user processes for capturing performance monitoring
> +data is governed by perf_event_mlock_kb [2]_ setting. This perf_event specific

by *the* perf_event_mlock_kb

> +*resource* setting defines overall per-cpu limits of memory allowed for mapping

Why the *emphasis* here?

> +by the user processes to execute performance monitoring. The setting essentially
> +extends RLIMIT_MEMLOCK [11]_ limit but only for memory regions mapped specially

extends *the* RMLIMIT_MEMLOCK limit *,* but only

> +for capturing monitored performance events and related data.
> +
> +For example, if a machine has eight cores and perf_event_mlock_kb limit is set
> +to 516 KiB then a user process is provided with 516 KiB * 8 = 4128 KiB of memory

Kib, then

> +above RLIMIT_MEMLOCK limit (ulimit -l) for perf_event mmap buffers. In particular

above *the* RLIMIT_MEMLOCK

particular,

> +this means that if the user wants to start two or more performance monitoring

that, if

> +processes, it is required to manually distribute available 4128 KiB between the

s/it is/they are/

> +monitoring processes, for example, using --mmap-pages Perf record mode option.

using *the* --mmap-pages option

> +Otherwise, the first started performance monitoring process allocates all available
> +4128 KiB and the other processes will fail to proceed due to the lack of memory.
> +
> +RLIMIT_MEMLOCK and perf_event_mlock_kb *resource* constraints are ignored for
> +processes with CAP_IPC_LOCK capability. Thus, perf_events/Perf privileged users

with *the* CAP_IPC_LOCK

> +can be provided with memory above the constraints for perf_events/Perf performance
> +monitoring purpose by providing the Perf executable with CAP_IPC_LOCK capability.
> +
>  Bibliography
>  ------------
>  
> @@ -94,4 +128,6 @@ Bibliography
>  .. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
>  .. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
>  .. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_
> +.. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_
> +.. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_

Thanks,

jon

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v1 3/3] perf-security: document perf_events/Perf resource control
  2019-02-01  7:30 ` [PATCH v1 3/3] perf-security: document perf_events/Perf resource control Alexey Budankov
@ 2019-02-07  0:01   ` Jonathan Corbet
  2019-02-07 13:14     ` Alexey Budankov
  0 siblings, 1 reply; 8+ messages in thread
From: Jonathan Corbet @ 2019-02-07  0:01 UTC (permalink / raw)
  To: Alexey Budankov
  Cc: Kees Cook, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
	Jann Horn, Arnaldo Carvalho de Melo, Jiri Olsa, Namhyung Kim,
	Alexander Shishkin, Mark Rutland, Andi Kleen, Tvrtko Ursulin,
	kernel-hardening, linux-doc, linux-kernel

On Fri, 1 Feb 2019 10:30:58 +0300
Alexey Budankov <alexey.budankov@linux.intel.com> wrote:

> Elaborate on possible perf_event/Perf privileged users groups
> and document steps about creating such groups.
> 
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
>  Documentation/admin-guide/perf-security.rst | 43 +++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
> index 7da7fa459718..fe90f8952be9 100644
> --- a/Documentation/admin-guide/perf-security.rst
> +++ b/Documentation/admin-guide/perf-security.rst
> @@ -73,6 +73,48 @@ enable capturing of additional data required for later performance analysis of
>  monitored processes or a system. For example, CAP_SYSLOG capability permits
>  reading kernel space memory addresses from /proc/kallsyms file.
>  
> +perf_events/Perf privileged users
> +---------------------------------
> +
> +Mechanisms of capabilities, privileged capability-dumb files [6]_ and file system
> +ACLs [10]_ can be used to create a dedicated group of perf_events/Perf privileged
> +users who are permitted to execute performance monitoring without *scope* limits.
> +The following steps can be taken to create such a group of privileged Perf users.
> +
> +1. Create perf_users group of privileged Perf users, assign perf_users group to
> +   Perf tool executable and limit *access* to the executable for other users in
> +   the system:
> +
> +::
> +
> +   # groupadd perf_users
> +   # ls -alhF
> +   -rwxr-xr-x  2 root root  11M Oct 19 15:12 perf
> +   # chgrp perf_users perf
> +   # ls -alhF
> +   -rwxr-xr-x  2 root perf_users  11M Oct 19 15:12 perf
> +   # chmod o-rwx perf
> +   # ls -alhF
> +   -rwxr-x---  2 root perf_users  11M Oct 19 15:12 perf

Since we're giving basic sysadmin info here, we should probably say
explicitly that this will block access to the perf binary to anybody who
is not in the perf_users group.

> +2. Assign required capabilities to the Perf tool executable file and enable

Assign *the* required

> +   members of perf_users group with performance monitoring privileges [6]_ :
> +
> +::
> +
> +   # setcap "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
> +   # setcap -v "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
> +   perf: OK
> +   # getcap perf
> +   perf = cap_sys_ptrace,cap_sys_admin,cap_syslog+ep
> +
> +As a result, members of perf_users group are capable of conducting performance
> +monitoring by using functionality of the configured Perf tool executable that,
> +when executes, passes perf_events subsystem *scope* checks.
> +
> +This specific *access* control management is only available to superuser or root

Why the *emphasis* here?  We prefer to minimize this kind of markup
whenever possible.

Thanks,

jon

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v1 3/3] perf-security: document perf_events/Perf resource control
  2019-02-07  0:01   ` Jonathan Corbet
@ 2019-02-07 13:14     ` Alexey Budankov
  0 siblings, 0 replies; 8+ messages in thread
From: Alexey Budankov @ 2019-02-07 13:14 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Kees Cook, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
	Jann Horn, Arnaldo Carvalho de Melo, Jiri Olsa, Namhyung Kim,
	Alexander Shishkin, Mark Rutland, Andi Kleen, Tvrtko Ursulin,
	kernel-hardening, linux-doc, linux-kernel


On 07.02.2019 3:01, Jonathan Corbet wrote:
> On Fri, 1 Feb 2019 10:30:58 +0300
> Alexey Budankov <alexey.budankov@linux.intel.com> wrote:
> 
>> Elaborate on possible perf_event/Perf privileged users groups
>> and document steps about creating such groups.
>>
>> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
>> ---
>>  Documentation/admin-guide/perf-security.rst | 43 +++++++++++++++++++++
>>  1 file changed, 43 insertions(+)
>>
>> diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
>> index 7da7fa459718..fe90f8952be9 100644
>> --- a/Documentation/admin-guide/perf-security.rst
>> +++ b/Documentation/admin-guide/perf-security.rst
>> @@ -73,6 +73,48 @@ enable capturing of additional data required for later performance analysis of
>>  monitored processes or a system. For example, CAP_SYSLOG capability permits
>>  reading kernel space memory addresses from /proc/kallsyms file.
>>  
>> +perf_events/Perf privileged users
>> +---------------------------------
>> +
>> +Mechanisms of capabilities, privileged capability-dumb files [6]_ and file system
>> +ACLs [10]_ can be used to create a dedicated group of perf_events/Perf privileged
>> +users who are permitted to execute performance monitoring without *scope* limits.
>> +The following steps can be taken to create such a group of privileged Perf user
>> +
>> +1. Create perf_users group of privileged Perf users, assign perf_users group to
>> +   Perf tool executable and limit *access* to the executable for other users in
>> +   the system:
>> +
>> +::
>> +
>> +   # groupadd perf_users
>> +   # ls -alhF
>> +   -rwxr-xr-x  2 root root  11M Oct 19 15:12 perf
>> +   # chgrp perf_users perf
>> +   # ls -alhF
>> +   -rwxr-xr-x  2 root perf_users  11M Oct 19 15:12 perf
>> +   # chmod o-rwx perf
>> +   # ls -alhF
>> +   -rwxr-x---  2 root perf_users  11M Oct 19 15:12 perf
> 
> Since we're giving basic sysadmin info here, we should probably say
> explicitly that this will block access to the perf binary to anybody who
> is not in the perf_users group.

We already say that above:
	"limit *access* to the executable for other users in the system".

Let's have it this way then:
	"limit access to the executable for other users in the system 
         who are not in the perf_users group".

> 
>> +2. Assign required capabilities to the Perf tool executable file and enable
> 
> Assign *the* required

Accepted.

> 
>> +   members of perf_users group with performance monitoring privileges [6]_ :
>> +
>> +::
>> +
>> +   # setcap "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
>> +   # setcap -v "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
>> +   perf: OK
>> +   # getcap perf
>> +   perf = cap_sys_ptrace,cap_sys_admin,cap_syslog+ep
>> +
>> +As a result, members of perf_users group are capable of conducting performance
>> +monitoring by using functionality of the configured Perf tool executable that,
>> +when executes, passes perf_events subsystem *scope* checks.
>> +
>> +This specific *access* control management is only available to superuser or root
> 
> Why the *emphasis* here?  We prefer to minimize this kind of markup
> whenever possible.

Avoided emphasis here and in the other places of this paragraph.

> 
> Thanks,
> 
> jon
> 

Thanks,
Alexey

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v1 1/3] perf-security: document perf_events/Perf resource control
  2019-02-06 23:58   ` Jonathan Corbet
@ 2019-02-07 13:14     ` Alexey Budankov
  0 siblings, 0 replies; 8+ messages in thread
From: Alexey Budankov @ 2019-02-07 13:14 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Kees Cook, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
	Jann Horn, Arnaldo Carvalho de Melo, Jiri Olsa, Namhyung Kim,
	Alexander Shishkin, Mark Rutland, Andi Kleen, Tvrtko Ursulin,
	kernel-hardening, linux-doc, linux-kernel


On 07.02.2019 2:58, Jonathan Corbet wrote:
> On Fri, 1 Feb 2019 10:29:11 +0300
> Alexey Budankov <alexey.budankov@linux.intel.com> wrote:
> 
>> Extend perf-security.rst file with perf_events/Perf resource control
>> section describing RLIMIT_NOFILE and perf_event_mlock_kb settings for
>> performance monitoring user processes.
>>
>> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> 
> Overall these patches seem reasonable, though I have some nits to pick.
> I'm happy to apply them but wouldn't mind an ack from the perf camp.
> 
> Alexey, could you wrap your paragraphs at 72-75 columns?

Sure, let's have it as the forth patch in the series in order not to 
mix the actual content with formatting.

> 
>> ---
>>  Documentation/admin-guide/perf-security.rst | 36 +++++++++++++++++++++
>>  1 file changed, 36 insertions(+)
>>
>> diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
>> index f73ebfe9bfe2..ff6832191577 100644
>> --- a/Documentation/admin-guide/perf-security.rst
>> +++ b/Documentation/admin-guide/perf-security.rst
>> @@ -84,6 +84,40 @@ governed by perf_event_paranoid [2]_ setting:
>>       locking limit is imposed but ignored for unprivileged processes with
>>       CAP_IPC_LOCK capability.
>>  
>> +perf_events/Perf resource control
>> +---------------------------------
>> +
>> +perf_events system call API [2]_ allocates file descriptors for every configured
> 
> *The* perf_events system call API

Accepted.

> 
>> +PMU event. Open file descriptors are a per-process accountable *resource* governed
>> +by RLIMIT_NOFILE [11]_ limit (ulimit -n), which is usually derived from the login
> 
> by *the* RLIMIT_NOFILE

Accepted.

> 
>> +shell process. When configuring Perf collection for a long list of events on a
>> +large server system, this limit can be easily hit preventing required monitoring
>> +configuration. RLIMIT_NOFILE limit can be increased on per-user basis modifying
>> +content of limits.conf file [12]_ on some systems. Ordinary Perf sampling session
> 
> of *the* limits.conf file
> 
> Ordinarily, a Perf

Accepted.

> 
>> +(perf record) requires an amount of open perf_event file descriptors that is not
>> +less than a number of monitored events multiplied by a number of monitored CPUs.
>> +
>> +An amount of memory available to user processes for capturing performance monitoring
>> +data is governed by perf_event_mlock_kb [2]_ setting. This perf_event specific
> 
> by *the* perf_event_mlock_kb

Accepted.

> 
>> +*resource* setting defines overall per-cpu limits of memory allowed for mapping
> 
> Why the *emphasis* here?

Avoided emphasis here and in the other places of this paragraphs.

> 
>> +by the user processes to execute performance monitoring. The setting essentially
>> +extends RLIMIT_MEMLOCK [11]_ limit but only for memory regions mapped specially
> 
> extends *the* RMLIMIT_MEMLOCK limit *,* but only

Accepted.

> 
>> +for capturing monitored performance events and related data.
>> +
>> +For example, if a machine has eight cores and perf_event_mlock_kb limit is set
>> +to 516 KiB then a user process is provided with 516 KiB * 8 = 4128 KiB of memory
> 
> Kib, then

Comma accepted, Kib = 1024 bits and this is not what is meant here - KiB=1024 Bytes.

> 
>> +above RLIMIT_MEMLOCK limit (ulimit -l) for perf_event mmap buffers. In particular
> 
> above *the* RLIMIT_MEMLOCK
> 
> particular,

Accepted.

> 
>> +this means that if the user wants to start two or more performance monitoring
> 
> that, if

Accepted.

> 
>> +processes, it is required to manually distribute available 4128 KiB between the
> 
> s/it is/they are/

Not sure what you mean here. I want to say that the users is required to distribute 
memory among the processes using --mmap-pages. Replaced 'it' with 'the user'.

> 
>> +monitoring processes, for example, using --mmap-pages Perf record mode option.
> 
> using *the* --mmap-pages option

Accepted.

> 
>> +Otherwise, the first started performance monitoring process allocates all available
>> +4128 KiB and the other processes will fail to proceed due to the lack of memory.
>> +
>> +RLIMIT_MEMLOCK and perf_event_mlock_kb *resource* constraints are ignored for
>> +processes with CAP_IPC_LOCK capability. Thus, perf_events/Perf privileged users
> 
> with *the* CAP_IPC_LOCK

Accepted.

> 
>> +can be provided with memory above the constraints for perf_events/Perf performance
>> +monitoring purpose by providing the Perf executable with CAP_IPC_LOCK capability.
>> +
>>  Bibliography
>>  ------------
>>  
>> @@ -94,4 +128,6 @@ Bibliography
>>  .. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
>>  .. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
>>  .. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_
>> +.. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_
>> +.. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_
> 
> Thanks,
> 
> jon
> 

Thanks,
Alexey

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-02-07 13:14 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-01  7:23 [PATCH v1 0/3] admin-guide: extend perf-security with resource control, data categories and privileged users Alexey Budankov
2019-02-01  7:29 ` [PATCH v1 1/3] perf-security: document perf_events/Perf resource control Alexey Budankov
2019-02-06 23:58   ` Jonathan Corbet
2019-02-07 13:14     ` Alexey Budankov
2019-02-01  7:30 ` [PATCH v1 2/3] perf-security: document collected perf_events/Perf data categories Alexey Budankov
2019-02-01  7:30 ` [PATCH v1 3/3] perf-security: document perf_events/Perf resource control Alexey Budankov
2019-02-07  0:01   ` Jonathan Corbet
2019-02-07 13:14     ` Alexey Budankov

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).