[d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vitaly Chikunov]

From: Ben Hutchings <ben@decadent.org.uk>

https://lkml.org/lkml/2016/1/11/587

The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
option to disable perf_event_open() entirely for unprivileged users.
This standalone version doesn't include making the variable read-only
(or renaming it).

When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.

This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
the variable read-only.  It also allows enabling further restriction
at run-time regardless of whether the default is changed.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
[ saf: resolve conflicts with v5.8-rc1 ]
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
[ vt: Make it default y. ]
Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
---
 include/linux/perf_event.h |  6 ++++++
 kernel/events/core.c       |  8 ++++++++
 security/Kconfig           | 10 ++++++++++
 3 files changed, 24 insertions(+)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 733649184b27..b00607abbcdf 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1342,6 +1342,12 @@ int perf_event_max_stack_handler(struct ctl_table *table, int write,
 #define PERF_SECURITY_CPU		1
 #define PERF_SECURITY_KERNEL		2
 #define PERF_SECURITY_TRACEPOINT	3
+#define PERF_SECURITY_MAX		4
+
+static inline bool perf_paranoid_any(void)
+{
+	return sysctl_perf_event_paranoid >= PERF_SECURITY_MAX;
+}
 
 static inline int perf_is_paranoid(void)
 {
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 2d7a23a7507b..15a3b37ae213 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -414,8 +414,13 @@ static struct kmem_cache *perf_event_cache;
  *   0 - disallow raw tracepoint access for unpriv
  *   1 - disallow cpu events for unpriv
  *   2 - disallow kernel profiling for unpriv
+ *   4 - disallow all unpriv perf event use
  */
+#ifdef CONFIG_SECURITY_PERF_EVENTS_RESTRICT
+int sysctl_perf_event_paranoid __read_mostly = PERF_SECURITY_MAX;
+#else
 int sysctl_perf_event_paranoid __read_mostly = 2;
+#endif
 
 /* Minimum for 512 kiB + 1 user control page */
 int sysctl_perf_event_mlock __read_mostly = 512 + (PAGE_SIZE / 1024); /* 'free' kiB per user */
@@ -12148,6 +12153,9 @@ SYSCALL_DEFINE5(perf_event_open,
 	if (err)
 		return err;
 
+	if (perf_paranoid_any() && !capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
 	err = perf_copy_attr(attr_uptr, &attr);
 	if (err)
 		return err;
diff --git a/security/Kconfig b/security/Kconfig
index 6c7b35c941c7..4861085a2d49 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -19,6 +19,16 @@ config SECURITY_DMESG_RESTRICT
 
 	  If you are unsure how to answer this question, answer N.
 
+config SECURITY_PERF_EVENTS_RESTRICT
+	bool "Restrict unprivileged use of performance events"
+	depends on PERF_EVENTS
+	default y
+	help
+	  If you say Y here, the kernel.perf_event_paranoid sysctl
+	  will be set to 3 by default, and no unprivileged use of the
+	  perf_event_open syscall will be permitted unless it is
+	  changed.
+
 config SECURITY
 	bool "Enable different security models"
 	depends on SYSFS
-- 
2.33.2

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Dmitry V. Levin]

On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> 
> https://lkml.org/lkml/2016/1/11/587
> 
> The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> option to disable perf_event_open() entirely for unprivileged users.
> This standalone version doesn't include making the variable read-only
> (or renaming it).
> 
> When kernel.perf_event_open is set to 3 (or greater), disallow all
----------------------------------------^

> access to performance events by users without CAP_SYS_ADMIN.
> Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> makes this value the default.
> 
> This is based on a similar feature in grsecurity
> (CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
> the variable read-only.  It also allows enabling further restriction
> at run-time regardless of whether the default is changed.
> 
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> [ saf: resolve conflicts with v5.8-rc1 ]
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> [ vt: Make it default y. ]
> Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
> ---
>  include/linux/perf_event.h |  6 ++++++
>  kernel/events/core.c       |  8 ++++++++
>  security/Kconfig           | 10 ++++++++++
>  3 files changed, 24 insertions(+)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 733649184b27..b00607abbcdf 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -1342,6 +1342,12 @@ int perf_event_max_stack_handler(struct ctl_table *table, int write,
>  #define PERF_SECURITY_CPU		1
>  #define PERF_SECURITY_KERNEL		2
>  #define PERF_SECURITY_TRACEPOINT	3
> +#define PERF_SECURITY_MAX		4
----------------------------------------^

> +
> +static inline bool perf_paranoid_any(void)
> +{
> +	return sysctl_perf_event_paranoid >= PERF_SECURITY_MAX;
> +}
>  
>  static inline int perf_is_paranoid(void)
>  {
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 2d7a23a7507b..15a3b37ae213 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -414,8 +414,13 @@ static struct kmem_cache *perf_event_cache;
>   *   0 - disallow raw tracepoint access for unpriv
>   *   1 - disallow cpu events for unpriv
>   *   2 - disallow kernel profiling for unpriv
> + *   4 - disallow all unpriv perf event use
--------^

>   */
> +#ifdef CONFIG_SECURITY_PERF_EVENTS_RESTRICT
> +int sysctl_perf_event_paranoid __read_mostly = PERF_SECURITY_MAX;
> +#else
>  int sysctl_perf_event_paranoid __read_mostly = 2;
> +#endif
>  
>  /* Minimum for 512 kiB + 1 user control page */
>  int sysctl_perf_event_mlock __read_mostly = 512 + (PAGE_SIZE / 1024); /* 'free' kiB per user */
> @@ -12148,6 +12153,9 @@ SYSCALL_DEFINE5(perf_event_open,
>  	if (err)
>  		return err;
>  
> +	if (perf_paranoid_any() && !capable(CAP_SYS_ADMIN))
> +		return -EACCES;
> +
>  	err = perf_copy_attr(attr_uptr, &attr);
>  	if (err)
>  		return err;
> diff --git a/security/Kconfig b/security/Kconfig
> index 6c7b35c941c7..4861085a2d49 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -19,6 +19,16 @@ config SECURITY_DMESG_RESTRICT
>  
>  	  If you are unsure how to answer this question, answer N.
>  
> +config SECURITY_PERF_EVENTS_RESTRICT
> +	bool "Restrict unprivileged use of performance events"
> +	depends on PERF_EVENTS
> +	default y
> +	help
> +	  If you say Y here, the kernel.perf_event_paranoid sysctl
> +	  will be set to 3 by default, and no unprivileged use of the
-------------------------^


-- 
ldv

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vitaly Chikunov]

Dmitry,

On Thu, Jun 02, 2022 at 10:14:38AM +0300, Dmitry V. Levin wrote:
> On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > From: Ben Hutchings <ben@decadent.org.uk>
> > 
> > https://lkml.org/lkml/2016/1/11/587
> > 
> > The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> > option to disable perf_event_open() entirely for unprivileged users.
> > This standalone version doesn't include making the variable read-only
> > (or renaming it).
> > 
> > When kernel.perf_event_open is set to 3 (or greater), disallow all
> ----------------------------------------^
> 
> > access to performance events by users without CAP_SYS_ADMIN.
> > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> > makes this value the default.
> > 
> > This is based on a similar feature in grsecurity
> > (CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
> > the variable read-only.  It also allows enabling further restriction
> > at run-time regardless of whether the default is changed.
> > 
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> > [ saf: resolve conflicts with v5.8-rc1 ]
> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> > [ vt: Make it default y. ]
> > Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
> > ---
> >  include/linux/perf_event.h |  6 ++++++
> >  kernel/events/core.c       |  8 ++++++++
> >  security/Kconfig           | 10 ++++++++++
> >  3 files changed, 24 insertions(+)
> > 
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index 733649184b27..b00607abbcdf 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
> > @@ -1342,6 +1342,12 @@ int perf_event_max_stack_handler(struct ctl_table *table, int write,
> >  #define PERF_SECURITY_CPU		1
> >  #define PERF_SECURITY_KERNEL		2
> >  #define PERF_SECURITY_TRACEPOINT	3
> > +#define PERF_SECURITY_MAX		4
> ----------------------------------------^
> 
> > +
> > +static inline bool perf_paranoid_any(void)
> > +{
> > +	return sysctl_perf_event_paranoid >= PERF_SECURITY_MAX;
> > +}
> >  
> >  static inline int perf_is_paranoid(void)
> >  {
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 2d7a23a7507b..15a3b37ae213 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -414,8 +414,13 @@ static struct kmem_cache *perf_event_cache;
> >   *   0 - disallow raw tracepoint access for unpriv
> >   *   1 - disallow cpu events for unpriv
> >   *   2 - disallow kernel profiling for unpriv
> > + *   4 - disallow all unpriv perf event use
> --------^
> 
> >   */
> > +#ifdef CONFIG_SECURITY_PERF_EVENTS_RESTRICT
> > +int sysctl_perf_event_paranoid __read_mostly = PERF_SECURITY_MAX;
> > +#else
> >  int sysctl_perf_event_paranoid __read_mostly = 2;
> > +#endif
> >  
> >  /* Minimum for 512 kiB + 1 user control page */
> >  int sysctl_perf_event_mlock __read_mostly = 512 + (PAGE_SIZE / 1024); /* 'free' kiB per user */
> > @@ -12148,6 +12153,9 @@ SYSCALL_DEFINE5(perf_event_open,
> >  	if (err)
> >  		return err;
> >  
> > +	if (perf_paranoid_any() && !capable(CAP_SYS_ADMIN))
> > +		return -EACCES;
> > +
> >  	err = perf_copy_attr(attr_uptr, &attr);
> >  	if (err)
> >  		return err;
> > diff --git a/security/Kconfig b/security/Kconfig
> > index 6c7b35c941c7..4861085a2d49 100644
> > --- a/security/Kconfig
> > +++ b/security/Kconfig
> > @@ -19,6 +19,16 @@ config SECURITY_DMESG_RESTRICT
> >  
> >  	  If you are unsure how to answer this question, answer N.
> >  
> > +config SECURITY_PERF_EVENTS_RESTRICT
> > +	bool "Restrict unprivileged use of performance events"
> > +	depends on PERF_EVENTS
> > +	default y
> > +	help
> > +	  If you say Y here, the kernel.perf_event_paranoid sysctl
> > +	  will be set to 3 by default, and no unprivileged use of the
> -------------------------^

Я это заметил, но, думаю, так надо и оставить.

> 
> 
> -- 
> ldv
> _______________________________________________
> devel-kernel mailing list
> devel-kernel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-kernel

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vitaly Chikunov]

Dmitry,

On Thu, Jun 02, 2022 at 03:40:38PM +0300, Vitaly Chikunov wrote:
> On Thu, Jun 02, 2022 at 10:14:38AM +0300, Dmitry V. Levin wrote:
> > On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > > index 6c7b35c941c7..4861085a2d49 100644
> > > --- a/security/Kconfig
> > > +++ b/security/Kconfig
> > > @@ -19,6 +19,16 @@ config SECURITY_DMESG_RESTRICT
> > >  
> > >  	  If you are unsure how to answer this question, answer N.
> > >  
> > > +config SECURITY_PERF_EVENTS_RESTRICT
> > > +	bool "Restrict unprivileged use of performance events"
> > > +	depends on PERF_EVENTS
> > > +	default y
> > > +	help
> > > +	  If you say Y here, the kernel.perf_event_paranoid sysctl
> > > +	  will be set to 3 by default, and no unprivileged use of the
> > -------------------------^
> 
> Я это заметил, но, думаю, так надо и оставить.
> 

Поправил и добавил в очередь в p10.

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Alexey Sheplyakov]

Hi,

On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> option to disable perf_event_open() entirely for unprivileged users.
> This standalone version doesn't include making the variable read-only
> (or renaming it).
> 
> When kernel.perf_event_open is set to 3 (or greater), disallow all
> access to performance events by users without CAP_SYS_ADMIN.
> Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> makes this value the default.

No, thanks. Profiling on Linux is already more diffucult than it should be
Making things even more complicated is not appreciated at all.

Best regards,
	Alexey

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4800 bytes --]

On Thu, 2 Jun 2022 15:40:38 +0300 Vitaly Chikunov wrote:
> Dmitry,
> 
> On Thu, Jun 02, 2022 at 10:14:38AM +0300, Dmitry V. Levin wrote:
> > On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > > From: Ben Hutchings <ben@decadent.org.uk>
> > > 
> > > https://lkml.org/lkml/2016/1/11/587
> > > 
> > > The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> > > option to disable perf_event_open() entirely for unprivileged users.
> > > This standalone version doesn't include making the variable read-only
> > > (or renaming it).
> > > 
> > > When kernel.perf_event_open is set to 3 (or greater), disallow all
> > ----------------------------------------^
> > 
> > > access to performance events by users without CAP_SYS_ADMIN.
> > > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> > > makes this value the default.
> > > 
> > > This is based on a similar feature in grsecurity
> > > (CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
> > > the variable read-only.  It also allows enabling further restriction
> > > at run-time regardless of whether the default is changed.
> > > 
> > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > > Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> > > [ saf: resolve conflicts with v5.8-rc1 ]
> > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> > > [ vt: Make it default y. ]
> > > Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
> > > ---
> > >  include/linux/perf_event.h |  6 ++++++
> > >  kernel/events/core.c       |  8 ++++++++
> > >  security/Kconfig           | 10 ++++++++++
> > >  3 files changed, 24 insertions(+)
> > > 
> > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > index 733649184b27..b00607abbcdf 100644
> > > --- a/include/linux/perf_event.h
> > > +++ b/include/linux/perf_event.h
> > > @@ -1342,6 +1342,12 @@ int perf_event_max_stack_handler(struct ctl_table *table, int write,
> > >  #define PERF_SECURITY_CPU		1
> > >  #define PERF_SECURITY_KERNEL		2
> > >  #define PERF_SECURITY_TRACEPOINT	3
> > > +#define PERF_SECURITY_MAX		4
> > ----------------------------------------^
> > 
> > > +
> > > +static inline bool perf_paranoid_any(void)
> > > +{
> > > +	return sysctl_perf_event_paranoid >= PERF_SECURITY_MAX;
> > > +}
> > >  
> > >  static inline int perf_is_paranoid(void)
> > >  {
> > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > index 2d7a23a7507b..15a3b37ae213 100644
> > > --- a/kernel/events/core.c
> > > +++ b/kernel/events/core.c
> > > @@ -414,8 +414,13 @@ static struct kmem_cache *perf_event_cache;
> > >   *   0 - disallow raw tracepoint access for unpriv
> > >   *   1 - disallow cpu events for unpriv
> > >   *   2 - disallow kernel profiling for unpriv
> > > + *   4 - disallow all unpriv perf event use
> > --------^
> > 
> > >   */
> > > +#ifdef CONFIG_SECURITY_PERF_EVENTS_RESTRICT
> > > +int sysctl_perf_event_paranoid __read_mostly = PERF_SECURITY_MAX;
> > > +#else
> > >  int sysctl_perf_event_paranoid __read_mostly = 2;
> > > +#endif
> > >  
> > >  /* Minimum for 512 kiB + 1 user control page */
> > >  int sysctl_perf_event_mlock __read_mostly = 512 + (PAGE_SIZE / 1024); /* 'free' kiB per user */
> > > @@ -12148,6 +12153,9 @@ SYSCALL_DEFINE5(perf_event_open,
> > >  	if (err)
> > >  		return err;
> > >  
> > > +	if (perf_paranoid_any() && !capable(CAP_SYS_ADMIN))
> > > +		return -EACCES;
> > > +
> > >  	err = perf_copy_attr(attr_uptr, &attr);
> > >  	if (err)
> > >  		return err;
> > > diff --git a/security/Kconfig b/security/Kconfig
> > > index 6c7b35c941c7..4861085a2d49 100644
> > > --- a/security/Kconfig
> > > +++ b/security/Kconfig
> > > @@ -19,6 +19,16 @@ config SECURITY_DMESG_RESTRICT
> > >  
> > >  	  If you are unsure how to answer this question, answer N.
> > >  
> > > +config SECURITY_PERF_EVENTS_RESTRICT
> > > +	bool "Restrict unprivileged use of performance events"
> > > +	depends on PERF_EVENTS
> > > +	default y
> > > +	help
> > > +	  If you say Y here, the kernel.perf_event_paranoid sysctl
> > > +	  will be set to 3 by default, and no unprivileged use of the
> > -------------------------^
> 
> Я это заметил, но, думаю, так надо и оставить.

Можно пояснить зачем? Какие задачи планируется этим решить?
Считается ли нормальным, что профилировать нужно будет под рутом?
Всё же хотелось бы, чтоб пользователь мог полноценно заниматься
разработкой и отладкой приложений.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Dmitry V. Levin]

Hi,

On Thu, Jun 02, 2022 at 07:15:11PM +0400, Alexey Sheplyakov wrote:
> Hi,
> 
> On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> > option to disable perf_event_open() entirely for unprivileged users.
> > This standalone version doesn't include making the variable read-only
> > (or renaming it).
> > 
> > When kernel.perf_event_open is set to 3 (or greater), disallow all
> > access to performance events by users without CAP_SYS_ADMIN.
> > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> > makes this value the default.
> 
> No, thanks. Profiling on Linux is already more diffucult than it should be
> Making things even more complicated is not appreciated at all.

Since the kernel we are talking about is an universal kernel, it has to
suit needs of both those who care about basic security and those who do
profiling.  Thus, a patch that makes this control runtime configurable
is a long awaited one.  The only aspect worth discussing is the default
behaviour.


-- 
ldv

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vitaly Chikunov]

Andrey,

On Thu, Jun 02, 2022 at 06:58:41PM +0300, Andrey Savchenko wrote:
> On Thu, 2 Jun 2022 15:40:38 +0300 Vitaly Chikunov wrote:
> 
> Можно пояснить зачем? Какие задачи планируется этим решить?
> Считается ли нормальным, что профилировать нужно будет под рутом?
> Всё же хотелось бы, чтоб пользователь мог полноценно заниматься
> разработкой и отладкой приложений.

I collected votes:

  2 against adding the patch (you and Alexey)
  3 pro adding the patch (Dmitry, Gleb, Vladimir)
  1 and I am neutral.

> 
> Best regards,
> Andrew Savchenko



> _______________________________________________
> devel-kernel mailing list
> devel-kernel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-kernel

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vladimir D. Seleznev]

On Thu, Jun 02, 2022 at 06:58:41PM +0300, Andrey Savchenko wrote:
> On Thu, 2 Jun 2022 15:40:38 +0300 Vitaly Chikunov wrote:
> > Dmitry,
> > 
> > On Thu, Jun 02, 2022 at 10:14:38AM +0300, Dmitry V. Levin wrote:
> > > On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > > > From: Ben Hutchings <ben@decadent.org.uk>
> > > > 
> > > > https://lkml.org/lkml/2016/1/11/587
> > > > 
> > > > The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> > > > option to disable perf_event_open() entirely for unprivileged users.
> > > > This standalone version doesn't include making the variable read-only
> > > > (or renaming it).
> > > > 
> > > > When kernel.perf_event_open is set to 3 (or greater), disallow all
> > > ----------------------------------------^
> > > 
> > > > access to performance events by users without CAP_SYS_ADMIN.
> > > > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> > > > makes this value the default.
> > > > 
> > > > This is based on a similar feature in grsecurity
> > > > (CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
> > > > the variable read-only.  It also allows enabling further restriction
> > > > at run-time regardless of whether the default is changed.
> > > > 
> > > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > > > Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> > > > [ saf: resolve conflicts with v5.8-rc1 ]
> > > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> > > > [ vt: Make it default y. ]
> > > > Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
> > > > ---
> > > >  include/linux/perf_event.h |  6 ++++++
> > > >  kernel/events/core.c       |  8 ++++++++
> > > >  security/Kconfig           | 10 ++++++++++
> > > >  3 files changed, 24 insertions(+)
> > > > 
> > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > > index 733649184b27..b00607abbcdf 100644
> > > > --- a/include/linux/perf_event.h
> > > > +++ b/include/linux/perf_event.h
> > > > @@ -1342,6 +1342,12 @@ int perf_event_max_stack_handler(struct ctl_table *table, int write,
> > > >  #define PERF_SECURITY_CPU		1
> > > >  #define PERF_SECURITY_KERNEL		2
> > > >  #define PERF_SECURITY_TRACEPOINT	3
> > > > +#define PERF_SECURITY_MAX		4
> > > ----------------------------------------^
> > > 
> > > > +
> > > > +static inline bool perf_paranoid_any(void)
> > > > +{
> > > > +	return sysctl_perf_event_paranoid >= PERF_SECURITY_MAX;
> > > > +}
> > > >  
> > > >  static inline int perf_is_paranoid(void)
> > > >  {
> > > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > > index 2d7a23a7507b..15a3b37ae213 100644
> > > > --- a/kernel/events/core.c
> > > > +++ b/kernel/events/core.c
> > > > @@ -414,8 +414,13 @@ static struct kmem_cache *perf_event_cache;
> > > >   *   0 - disallow raw tracepoint access for unpriv
> > > >   *   1 - disallow cpu events for unpriv
> > > >   *   2 - disallow kernel profiling for unpriv
> > > > + *   4 - disallow all unpriv perf event use
> > > --------^
> > > 
> > > >   */
> > > > +#ifdef CONFIG_SECURITY_PERF_EVENTS_RESTRICT
> > > > +int sysctl_perf_event_paranoid __read_mostly = PERF_SECURITY_MAX;
> > > > +#else
> > > >  int sysctl_perf_event_paranoid __read_mostly = 2;
> > > > +#endif
> > > >  
> > > >  /* Minimum for 512 kiB + 1 user control page */
> > > >  int sysctl_perf_event_mlock __read_mostly = 512 + (PAGE_SIZE / 1024); /* 'free' kiB per user */
> > > > @@ -12148,6 +12153,9 @@ SYSCALL_DEFINE5(perf_event_open,
> > > >  	if (err)
> > > >  		return err;
> > > >  
> > > > +	if (perf_paranoid_any() && !capable(CAP_SYS_ADMIN))
> > > > +		return -EACCES;
> > > > +
> > > >  	err = perf_copy_attr(attr_uptr, &attr);
> > > >  	if (err)
> > > >  		return err;
> > > > diff --git a/security/Kconfig b/security/Kconfig
> > > > index 6c7b35c941c7..4861085a2d49 100644
> > > > --- a/security/Kconfig
> > > > +++ b/security/Kconfig
> > > > @@ -19,6 +19,16 @@ config SECURITY_DMESG_RESTRICT
> > > >  
> > > >  	  If you are unsure how to answer this question, answer N.
> > > >  
> > > > +config SECURITY_PERF_EVENTS_RESTRICT
> > > > +	bool "Restrict unprivileged use of performance events"
> > > > +	depends on PERF_EVENTS
> > > > +	default y
> > > > +	help
> > > > +	  If you say Y here, the kernel.perf_event_paranoid sysctl
> > > > +	  will be set to 3 by default, and no unprivileged use of the
> > > -------------------------^
> > 
> > Я это заметил, но, думаю, так надо и оставить.
> 
> Можно пояснить зачем? Какие задачи планируется этим решить?
> Считается ли нормальным, что профилировать нужно будет под рутом?
> Всё же хотелось бы, чтоб пользователь мог полноценно заниматься
> разработкой и отладкой приложений.

Не сказать, что профилирование — типичная задача. Если есть потребность
профилировать не из-под рута, то ничего не мешает переключить ручку на
подходящее значение.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 6188 bytes --]

On Thu, 2 Jun 2022 21:26:36 +0300 Vladimir D. Seleznev wrote:
> On Thu, Jun 02, 2022 at 06:58:41PM +0300, Andrey Savchenko wrote:
> > On Thu, 2 Jun 2022 15:40:38 +0300 Vitaly Chikunov wrote:
> > > Dmitry,
> > > 
> > > On Thu, Jun 02, 2022 at 10:14:38AM +0300, Dmitry V. Levin wrote:
> > > > On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > > > > From: Ben Hutchings <ben@decadent.org.uk>
> > > > > 
> > > > > https://lkml.org/lkml/2016/1/11/587
> > > > > 
> > > > > The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> > > > > option to disable perf_event_open() entirely for unprivileged users.
> > > > > This standalone version doesn't include making the variable read-only
> > > > > (or renaming it).
> > > > > 
> > > > > When kernel.perf_event_open is set to 3 (or greater), disallow all
> > > > ----------------------------------------^
> > > > 
> > > > > access to performance events by users without CAP_SYS_ADMIN.
> > > > > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> > > > > makes this value the default.
> > > > > 
> > > > > This is based on a similar feature in grsecurity
> > > > > (CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
> > > > > the variable read-only.  It also allows enabling further restriction
> > > > > at run-time regardless of whether the default is changed.
> > > > > 
> > > > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > > > > Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> > > > > [ saf: resolve conflicts with v5.8-rc1 ]
> > > > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> > > > > [ vt: Make it default y. ]
> > > > > Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
> > > > > ---
> > > > >  include/linux/perf_event.h |  6 ++++++
> > > > >  kernel/events/core.c       |  8 ++++++++
> > > > >  security/Kconfig           | 10 ++++++++++
> > > > >  3 files changed, 24 insertions(+)
> > > > > 
> > > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > > > index 733649184b27..b00607abbcdf 100644
> > > > > --- a/include/linux/perf_event.h
> > > > > +++ b/include/linux/perf_event.h
> > > > > @@ -1342,6 +1342,12 @@ int perf_event_max_stack_handler(struct ctl_table *table, int write,
> > > > >  #define PERF_SECURITY_CPU		1
> > > > >  #define PERF_SECURITY_KERNEL		2
> > > > >  #define PERF_SECURITY_TRACEPOINT	3
> > > > > +#define PERF_SECURITY_MAX		4
> > > > ----------------------------------------^
> > > > 
> > > > > +
> > > > > +static inline bool perf_paranoid_any(void)
> > > > > +{
> > > > > +	return sysctl_perf_event_paranoid >= PERF_SECURITY_MAX;
> > > > > +}
> > > > >  
> > > > >  static inline int perf_is_paranoid(void)
> > > > >  {
> > > > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > > > index 2d7a23a7507b..15a3b37ae213 100644
> > > > > --- a/kernel/events/core.c
> > > > > +++ b/kernel/events/core.c
> > > > > @@ -414,8 +414,13 @@ static struct kmem_cache *perf_event_cache;
> > > > >   *   0 - disallow raw tracepoint access for unpriv
> > > > >   *   1 - disallow cpu events for unpriv
> > > > >   *   2 - disallow kernel profiling for unpriv
> > > > > + *   4 - disallow all unpriv perf event use
> > > > --------^
> > > > 
> > > > >   */
> > > > > +#ifdef CONFIG_SECURITY_PERF_EVENTS_RESTRICT
> > > > > +int sysctl_perf_event_paranoid __read_mostly = PERF_SECURITY_MAX;
> > > > > +#else
> > > > >  int sysctl_perf_event_paranoid __read_mostly = 2;
> > > > > +#endif
> > > > >  
> > > > >  /* Minimum for 512 kiB + 1 user control page */
> > > > >  int sysctl_perf_event_mlock __read_mostly = 512 + (PAGE_SIZE / 1024); /* 'free' kiB per user */
> > > > > @@ -12148,6 +12153,9 @@ SYSCALL_DEFINE5(perf_event_open,
> > > > >  	if (err)
> > > > >  		return err;
> > > > >  
> > > > > +	if (perf_paranoid_any() && !capable(CAP_SYS_ADMIN))
> > > > > +		return -EACCES;
> > > > > +
> > > > >  	err = perf_copy_attr(attr_uptr, &attr);
> > > > >  	if (err)
> > > > >  		return err;
> > > > > diff --git a/security/Kconfig b/security/Kconfig
> > > > > index 6c7b35c941c7..4861085a2d49 100644
> > > > > --- a/security/Kconfig
> > > > > +++ b/security/Kconfig
> > > > > @@ -19,6 +19,16 @@ config SECURITY_DMESG_RESTRICT
> > > > >  
> > > > >  	  If you are unsure how to answer this question, answer N.
> > > > >  
> > > > > +config SECURITY_PERF_EVENTS_RESTRICT
> > > > > +	bool "Restrict unprivileged use of performance events"
> > > > > +	depends on PERF_EVENTS
> > > > > +	default y
> > > > > +	help
> > > > > +	  If you say Y here, the kernel.perf_event_paranoid sysctl
> > > > > +	  will be set to 3 by default, and no unprivileged use of the
> > > > -------------------------^
> > > 
> > > Я это заметил, но, думаю, так надо и оставить.
> > 
> > Можно пояснить зачем? Какие задачи планируется этим решить?
> > Считается ли нормальным, что профилировать нужно будет под рутом?
> > Всё же хотелось бы, чтоб пользователь мог полноценно заниматься
> > разработкой и отладкой приложений.
> 
> Не сказать, что профилирование — типичная задача. Если есть потребность
> профилировать не из-под рута, то ничего не мешает переключить ручку на
> подходящее значение.

И сделать ребут, да?

А профилирование ведь не только разработчику нужно, но и админу,
особенно на высоконагруженных системах для поиска узких мест.

Т.е. в реальности всё будет от рута делаться и безопасность
промышленных систем и систем разработки будет деградирована.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Dmitry V. Levin]

On Thu, Jun 02, 2022 at 09:42:03PM +0300, Andrey Savchenko wrote:
[...]
> И сделать ребут, да?

Зачем ребут, это же sysctl.


-- 
ldv

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vladimir D. Seleznev]

On Thu, Jun 02, 2022 at 09:42:03PM +0300, Andrey Savchenko wrote:
> On Thu, 2 Jun 2022 21:26:36 +0300 Vladimir D. Seleznev wrote:
> > On Thu, Jun 02, 2022 at 06:58:41PM +0300, Andrey Savchenko wrote:
> > > On Thu, 2 Jun 2022 15:40:38 +0300 Vitaly Chikunov wrote:
> > > > Dmitry,
> > > > 
> > > > On Thu, Jun 02, 2022 at 10:14:38AM +0300, Dmitry V. Levin wrote:
> > > > > On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > > > > > From: Ben Hutchings <ben@decadent.org.uk>
> > > > > > 
> > > > > > https://lkml.org/lkml/2016/1/11/587
> > > > > > 
> > > > > > The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> > > > > > option to disable perf_event_open() entirely for unprivileged users.
> > > > > > This standalone version doesn't include making the variable read-only
> > > > > > (or renaming it).
> > > > > > 
> > > > > > When kernel.perf_event_open is set to 3 (or greater), disallow all
> > > > > ----------------------------------------^
> > > > > 
> > > > > > access to performance events by users without CAP_SYS_ADMIN.
> > > > > > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> > > > > > makes this value the default.
> > > > > > 
> > > > > > This is based on a similar feature in grsecurity
> > > > > > (CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
> > > > > > the variable read-only.  It also allows enabling further restriction
> > > > > > at run-time regardless of whether the default is changed.
> > > > > > 
> > > > > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > > > > > Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> > > > > > [ saf: resolve conflicts with v5.8-rc1 ]
> > > > > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> > > > > > [ vt: Make it default y. ]
> > > > > > Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
> > > > > > ---
> > > > > >  include/linux/perf_event.h |  6 ++++++
> > > > > >  kernel/events/core.c       |  8 ++++++++
> > > > > >  security/Kconfig           | 10 ++++++++++
> > > > > >  3 files changed, 24 insertions(+)
> > > > > > 
> > > > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > > > > index 733649184b27..b00607abbcdf 100644
> > > > > > --- a/include/linux/perf_event.h
> > > > > > +++ b/include/linux/perf_event.h
> > > > > > @@ -1342,6 +1342,12 @@ int perf_event_max_stack_handler(struct ctl_table *table, int write,
> > > > > >  #define PERF_SECURITY_CPU		1
> > > > > >  #define PERF_SECURITY_KERNEL		2
> > > > > >  #define PERF_SECURITY_TRACEPOINT	3
> > > > > > +#define PERF_SECURITY_MAX		4
> > > > > ----------------------------------------^
> > > > > 
> > > > > > +
> > > > > > +static inline bool perf_paranoid_any(void)
> > > > > > +{
> > > > > > +	return sysctl_perf_event_paranoid >= PERF_SECURITY_MAX;
> > > > > > +}
> > > > > >  
> > > > > >  static inline int perf_is_paranoid(void)
> > > > > >  {
> > > > > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > > > > index 2d7a23a7507b..15a3b37ae213 100644
> > > > > > --- a/kernel/events/core.c
> > > > > > +++ b/kernel/events/core.c
> > > > > > @@ -414,8 +414,13 @@ static struct kmem_cache *perf_event_cache;
> > > > > >   *   0 - disallow raw tracepoint access for unpriv
> > > > > >   *   1 - disallow cpu events for unpriv
> > > > > >   *   2 - disallow kernel profiling for unpriv
> > > > > > + *   4 - disallow all unpriv perf event use
> > > > > --------^
> > > > > 
> > > > > >   */
> > > > > > +#ifdef CONFIG_SECURITY_PERF_EVENTS_RESTRICT
> > > > > > +int sysctl_perf_event_paranoid __read_mostly = PERF_SECURITY_MAX;
> > > > > > +#else
> > > > > >  int sysctl_perf_event_paranoid __read_mostly = 2;
> > > > > > +#endif
> > > > > >  
> > > > > >  /* Minimum for 512 kiB + 1 user control page */
> > > > > >  int sysctl_perf_event_mlock __read_mostly = 512 + (PAGE_SIZE / 1024); /* 'free' kiB per user */
> > > > > > @@ -12148,6 +12153,9 @@ SYSCALL_DEFINE5(perf_event_open,
> > > > > >  	if (err)
> > > > > >  		return err;
> > > > > >  
> > > > > > +	if (perf_paranoid_any() && !capable(CAP_SYS_ADMIN))
> > > > > > +		return -EACCES;
> > > > > > +
> > > > > >  	err = perf_copy_attr(attr_uptr, &attr);
> > > > > >  	if (err)
> > > > > >  		return err;
> > > > > > diff --git a/security/Kconfig b/security/Kconfig
> > > > > > index 6c7b35c941c7..4861085a2d49 100644
> > > > > > --- a/security/Kconfig
> > > > > > +++ b/security/Kconfig
> > > > > > @@ -19,6 +19,16 @@ config SECURITY_DMESG_RESTRICT
> > > > > >  
> > > > > >  	  If you are unsure how to answer this question, answer N.
> > > > > >  
> > > > > > +config SECURITY_PERF_EVENTS_RESTRICT
> > > > > > +	bool "Restrict unprivileged use of performance events"
> > > > > > +	depends on PERF_EVENTS
> > > > > > +	default y
> > > > > > +	help
> > > > > > +	  If you say Y here, the kernel.perf_event_paranoid sysctl
> > > > > > +	  will be set to 3 by default, and no unprivileged use of the
> > > > > -------------------------^
> > > > 
> > > > Я это заметил, но, думаю, так надо и оставить.
> > > 
> > > Можно пояснить зачем? Какие задачи планируется этим решить?
> > > Считается ли нормальным, что профилировать нужно будет под рутом?
> > > Всё же хотелось бы, чтоб пользователь мог полноценно заниматься
> > > разработкой и отладкой приложений.
> > 
> > Не сказать, что профилирование — типичная задача. Если есть потребность
> > профилировать не из-под рута, то ничего не мешает переключить ручку на
> > подходящее значение.
> 
> И сделать ребут, да?
> 
> А профилирование ведь не только разработчику нужно, но и админу,
> особенно на высоконагруженных системах для поиска узких мест.
> 
> Т.е. в реальности всё будет от рута делаться и безопасность
> промышленных систем и систем разработки будет деградирована.

Насколько я помню, суперпользователь умеет сбрасывать привилегии.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 7234 bytes --]

On Thu, 2 Jun 2022 22:08:48 +0300 Vladimir D. Seleznev wrote:
> On Thu, Jun 02, 2022 at 09:42:03PM +0300, Andrey Savchenko wrote:
> > On Thu, 2 Jun 2022 21:26:36 +0300 Vladimir D. Seleznev wrote:
> > > On Thu, Jun 02, 2022 at 06:58:41PM +0300, Andrey Savchenko wrote:
> > > > On Thu, 2 Jun 2022 15:40:38 +0300 Vitaly Chikunov wrote:
> > > > > Dmitry,
> > > > > 
> > > > > On Thu, Jun 02, 2022 at 10:14:38AM +0300, Dmitry V. Levin wrote:
> > > > > > On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > > > > > > From: Ben Hutchings <ben@decadent.org.uk>
> > > > > > > 
> > > > > > > https://lkml.org/lkml/2016/1/11/587
> > > > > > > 
> > > > > > > The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> > > > > > > option to disable perf_event_open() entirely for unprivileged users.
> > > > > > > This standalone version doesn't include making the variable read-only
> > > > > > > (or renaming it).
> > > > > > > 
> > > > > > > When kernel.perf_event_open is set to 3 (or greater), disallow all
> > > > > > ----------------------------------------^
> > > > > > 
> > > > > > > access to performance events by users without CAP_SYS_ADMIN.
> > > > > > > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> > > > > > > makes this value the default.
> > > > > > > 
> > > > > > > This is based on a similar feature in grsecurity
> > > > > > > (CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
> > > > > > > the variable read-only.  It also allows enabling further restriction
> > > > > > > at run-time regardless of whether the default is changed.
> > > > > > > 
> > > > > > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > > > > > > Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> > > > > > > [ saf: resolve conflicts with v5.8-rc1 ]
> > > > > > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> > > > > > > [ vt: Make it default y. ]
> > > > > > > Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
> > > > > > > ---
> > > > > > >  include/linux/perf_event.h |  6 ++++++
> > > > > > >  kernel/events/core.c       |  8 ++++++++
> > > > > > >  security/Kconfig           | 10 ++++++++++
> > > > > > >  3 files changed, 24 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > > > > > index 733649184b27..b00607abbcdf 100644
> > > > > > > --- a/include/linux/perf_event.h
> > > > > > > +++ b/include/linux/perf_event.h
> > > > > > > @@ -1342,6 +1342,12 @@ int perf_event_max_stack_handler(struct ctl_table *table, int write,
> > > > > > >  #define PERF_SECURITY_CPU		1
> > > > > > >  #define PERF_SECURITY_KERNEL		2
> > > > > > >  #define PERF_SECURITY_TRACEPOINT	3
> > > > > > > +#define PERF_SECURITY_MAX		4
> > > > > > ----------------------------------------^
> > > > > > 
> > > > > > > +
> > > > > > > +static inline bool perf_paranoid_any(void)
> > > > > > > +{
> > > > > > > +	return sysctl_perf_event_paranoid >= PERF_SECURITY_MAX;
> > > > > > > +}
> > > > > > >  
> > > > > > >  static inline int perf_is_paranoid(void)
> > > > > > >  {
> > > > > > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > > > > > index 2d7a23a7507b..15a3b37ae213 100644
> > > > > > > --- a/kernel/events/core.c
> > > > > > > +++ b/kernel/events/core.c
> > > > > > > @@ -414,8 +414,13 @@ static struct kmem_cache *perf_event_cache;
> > > > > > >   *   0 - disallow raw tracepoint access for unpriv
> > > > > > >   *   1 - disallow cpu events for unpriv
> > > > > > >   *   2 - disallow kernel profiling for unpriv
> > > > > > > + *   4 - disallow all unpriv perf event use
> > > > > > --------^
> > > > > > 
> > > > > > >   */
> > > > > > > +#ifdef CONFIG_SECURITY_PERF_EVENTS_RESTRICT
> > > > > > > +int sysctl_perf_event_paranoid __read_mostly = PERF_SECURITY_MAX;
> > > > > > > +#else
> > > > > > >  int sysctl_perf_event_paranoid __read_mostly = 2;
> > > > > > > +#endif
> > > > > > >  
> > > > > > >  /* Minimum for 512 kiB + 1 user control page */
> > > > > > >  int sysctl_perf_event_mlock __read_mostly = 512 + (PAGE_SIZE / 1024); /* 'free' kiB per user */
> > > > > > > @@ -12148,6 +12153,9 @@ SYSCALL_DEFINE5(perf_event_open,
> > > > > > >  	if (err)
> > > > > > >  		return err;
> > > > > > >  
> > > > > > > +	if (perf_paranoid_any() && !capable(CAP_SYS_ADMIN))
> > > > > > > +		return -EACCES;
> > > > > > > +
> > > > > > >  	err = perf_copy_attr(attr_uptr, &attr);
> > > > > > >  	if (err)
> > > > > > >  		return err;
> > > > > > > diff --git a/security/Kconfig b/security/Kconfig
> > > > > > > index 6c7b35c941c7..4861085a2d49 100644
> > > > > > > --- a/security/Kconfig
> > > > > > > +++ b/security/Kconfig
> > > > > > > @@ -19,6 +19,16 @@ config SECURITY_DMESG_RESTRICT
> > > > > > >  
> > > > > > >  	  If you are unsure how to answer this question, answer N.
> > > > > > >  
> > > > > > > +config SECURITY_PERF_EVENTS_RESTRICT
> > > > > > > +	bool "Restrict unprivileged use of performance events"
> > > > > > > +	depends on PERF_EVENTS
> > > > > > > +	default y
> > > > > > > +	help
> > > > > > > +	  If you say Y here, the kernel.perf_event_paranoid sysctl
> > > > > > > +	  will be set to 3 by default, and no unprivileged use of the
> > > > > > -------------------------^
> > > > > 
> > > > > Я это заметил, но, думаю, так надо и оставить.
> > > > 
> > > > Можно пояснить зачем? Какие задачи планируется этим решить?
> > > > Считается ли нормальным, что профилировать нужно будет под рутом?
> > > > Всё же хотелось бы, чтоб пользователь мог полноценно заниматься
> > > > разработкой и отладкой приложений.
> > > 
> > > Не сказать, что профилирование — типичная задача. Если есть потребность
> > > профилировать не из-под рута, то ничего не мешает переключить ручку на
> > > подходящее значение.
> > 
> > И сделать ребут, да?
> > 
> > А профилирование ведь не только разработчику нужно, но и админу,
> > особенно на высоконагруженных системах для поиска узких мест.
> > 
> > Т.е. в реальности всё будет от рута делаться и безопасность
> > промышленных систем и систем разработки будет деградирована.
> 
> Насколько я помню, суперпользователь умеет сбрасывать привилегии.

Речь идёт в первую очередь о запуске утилиты perf. Мне не известно о
том, что она умеет сбрасывать привилегии. Если я не прав, прошу
указать в мане, я не нашёл. 

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

On Thu, 2 Jun 2022 19:39:14 +0300 Dmitry V. Levin wrote:
> Hi,
> 
> On Thu, Jun 02, 2022 at 07:15:11PM +0400, Alexey Sheplyakov wrote:
> > Hi,
> > 
> > On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > > The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> > > option to disable perf_event_open() entirely for unprivileged users.
> > > This standalone version doesn't include making the variable read-only
> > > (or renaming it).
> > > 
> > > When kernel.perf_event_open is set to 3 (or greater), disallow all
> > > access to performance events by users without CAP_SYS_ADMIN.
> > > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> > > makes this value the default.
> > 
> > No, thanks. Profiling on Linux is already more diffucult than it should be
> > Making things even more complicated is not appreciated at all.
> 
> Since the kernel we are talking about is an universal kernel, it has to
> suit needs of both those who care about basic security and those who do
> profiling.  Thus, a patch that makes this control runtime configurable
> is a long awaited one.  The only aspect worth discussing is the default
> behaviour.
 
We should be consistent is this behaviour. Why do we have ptrace
allowed for unprivileged users then? It provides a broad scope for
attacks.

We should set /proc/sys/kernel/yama/ptrace_scope to at least 2 by
default. Though this is not a kernel-configurable option, but
a sysctl's one.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

On Thu, 2 Jun 2022 21:56:50 +0300 Dmitry V. Levin wrote:
> On Thu, Jun 02, 2022 at 09:42:03PM +0300, Andrey Savchenko wrote:
> [...]
> > И сделать ребут, да?
> 
> Зачем ребут, это же sysctl.
 
Хорошо, значит я не так понял исходное сообщение.
Тогда проблема действительно не так страшна.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vladimir D. Seleznev]

On Fri, Jun 03, 2022 at 09:16:10AM +0300, Andrey Savchenko wrote:
> On Thu, 2 Jun 2022 22:08:48 +0300 Vladimir D. Seleznev wrote:
> > On Thu, Jun 02, 2022 at 09:42:03PM +0300, Andrey Savchenko wrote:
> > > On Thu, 2 Jun 2022 21:26:36 +0300 Vladimir D. Seleznev wrote:
> > > > On Thu, Jun 02, 2022 at 06:58:41PM +0300, Andrey Savchenko wrote:
> > > > > On Thu, 2 Jun 2022 15:40:38 +0300 Vitaly Chikunov wrote:
> > > [...]
> > 
> > Насколько я помню, суперпользователь умеет сбрасывать привилегии.
> 
> Речь идёт в первую очередь о запуске утилиты perf. Мне не известно о
> том, что она умеет сбрасывать привилегии. Если я не прав, прошу
> указать в мане, я не нашёл. 

man setpriv

-- 
   WBR,
   Vladimir D. Seleznev

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

On Fri, 3 Jun 2022 15:41:35 +0300 Vladimir D. Seleznev wrote:
> On Fri, Jun 03, 2022 at 09:16:10AM +0300, Andrey Savchenko wrote:
> > On Thu, 2 Jun 2022 22:08:48 +0300 Vladimir D. Seleznev wrote:
> > > On Thu, Jun 02, 2022 at 09:42:03PM +0300, Andrey Savchenko wrote:
> > > > On Thu, 2 Jun 2022 21:26:36 +0300 Vladimir D. Seleznev wrote:
> > > > > On Thu, Jun 02, 2022 at 06:58:41PM +0300, Andrey Savchenko wrote:
> > > > > > On Thu, 2 Jun 2022 15:40:38 +0300 Vitaly Chikunov wrote:
> > > > [...]
> > > 
> > > Насколько я помню, суперпользователь умеет сбрасывать привилегии.
> > 
> > Речь идёт в первую очередь о запуске утилиты perf. Мне не известно о
> > том, что она умеет сбрасывать привилегии. Если я не прав, прошу
> > указать в мане, я не нашёл. 
> 
> man setpriv

Очевидно, это не то: setpriv позволяет запустить программу
с пониженными привилегиями. Здесь же нужен сброс привилегий самим
приложением после того, как оно использовало привилегированный
доступ к счётчикам perf. Притом вполне возможно, что это доступ
нужно будет сохранять в процессе работы, поэтому нужно серьёзное
переписывание perf для разделения работы на привилегированный
и непривилегированный процессы.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vitaly Chikunov]

On Fri, Jun 03, 2022 at 09:25:46AM +0300, Andrey Savchenko wrote:
> On Thu, 2 Jun 2022 19:39:14 +0300 Dmitry V. Levin wrote:
> > Hi,
> > 
> > On Thu, Jun 02, 2022 at 07:15:11PM +0400, Alexey Sheplyakov wrote:
> > > Hi,
> > > 
> > > On Thu, Jun 02, 2022 at 03:31:00AM +0300, Vitaly Chikunov wrote:
> > > > The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
> > > > option to disable perf_event_open() entirely for unprivileged users.
> > > > This standalone version doesn't include making the variable read-only
> > > > (or renaming it).
> > > > 
> > > > When kernel.perf_event_open is set to 3 (or greater), disallow all
> > > > access to performance events by users without CAP_SYS_ADMIN.
> > > > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> > > > makes this value the default.
> > > 
> > > No, thanks. Profiling on Linux is already more diffucult than it should be
> > > Making things even more complicated is not appreciated at all.
> > 
> > Since the kernel we are talking about is an universal kernel, it has to
> > suit needs of both those who care about basic security and those who do
> > profiling.  Thus, a patch that makes this control runtime configurable
> > is a long awaited one.  The only aspect worth discussing is the default
> > behaviour.
>  
> We should be consistent is this behaviour. Why do we have ptrace
> allowed for unprivileged users then? It provides a broad scope for
> attacks.
> 
> We should set /proc/sys/kernel/yama/ptrace_scope to at least 2 by
> default. Though this is not a kernel-configurable option, but

We always can patch:

diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index 06e226166aab..7098bc50618b 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -24,7 +24,7 @@
 #define YAMA_SCOPE_CAPABILITY  2
 #define YAMA_SCOPE_NO_ATTACH   3

-static int ptrace_scope = YAMA_SCOPE_RELATIONAL;
+static int ptrace_scope = YAMA_SCOPE_CAPABILITY;

 /* describe a ptrace relationship for potential exception */
 struct ptrace_relation {


> a sysctl's one.
> 
> Best regards,
> Andrew Savchenko



> _______________________________________________
> devel-kernel mailing list
> devel-kernel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-kernel

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Alexey Sheplyakov]

Hello,

On Thu, Jun 02, 2022 at 07:39:14PM +0300, Dmitry V. Levin wrote:
> > No, thanks. Profiling on Linux is already more diffucult than it should be
> > Making things even more complicated is not appreciated at all.
> 
> Since the kernel we are talking about is an universal kernel, it has to
> suit needs of both those who care about basic security and those who do
> profiling.

Breaking a basic system functionality (such as debugging and profiling)
has nothing to do with security.

> Thus, a patch that makes this control runtime configurable is a long awaited one.

This statement is wrong. No people I know of need a knob to make their
system broken.

> The only aspect worth discussing is the default behaviour.

By default an ordinary user should be able to debug and profile his processes
(things used to work that way for several decades). Those who want a broken
system can break it without the newly added knob, i.e. by removing gdb and perf
(and mounting all user-writable filesystems with noexec option).

P.S.

People who actually need security 

1) don't use out-of-order CPUs (to avoid Meltdown, Spectre, etc)
2) don't use Linux (so the kernel can be actually audited)
3) don't exist

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Dmitry V. Levin]

Hi,

On Sun, Jun 05, 2022 at 11:48:06AM +0400, Alexey Sheplyakov wrote:
> Hello,
> 
> On Thu, Jun 02, 2022 at 07:39:14PM +0300, Dmitry V. Levin wrote:
> > > No, thanks. Profiling on Linux is already more diffucult than it should be
> > > Making things even more complicated is not appreciated at all.
> > 
> > Since the kernel we are talking about is a universal kernel, it has to
> > suit needs of both those who care about basic security and those who do
> > profiling.
> 
> Breaking a basic system functionality (such as debugging and profiling)
> has nothing to do with security.

Whatever you might consider a basic system functionality is your point of
view, other people are likely to have different use cases where some of
things your treat as basic are redundant or even dangerous.

With regards to debugging and profiling, I do have installs where neither
debugging nor profiling should be allowed, and we have a universal kernel
to achieve that.


-- 
ldv

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vladimir D. Seleznev]

On Sun, Jun 05, 2022 at 11:48:06AM +0400, Alexey Sheplyakov wrote:
> Hello,
> 
> On Thu, Jun 02, 2022 at 07:39:14PM +0300, Dmitry V. Levin wrote:
> > > No, thanks. Profiling on Linux is already more diffucult than it should be
> > > Making things even more complicated is not appreciated at all.
> > 
> > Since the kernel we are talking about is an universal kernel, it has to
> > suit needs of both those who care about basic security and those who do
> > profiling.
> 
> [...]
> 
> People who actually need security 
> 
> 1) don't use out-of-order CPUs (to avoid Meltdown, Spectre, etc)
> 2) don't use Linux (so the kernel can be actually audited)
> 3) don't exist

I don't get the point of these. If we don't need security why should we
bother with user/group processes/filesystems separation and permissions,
chrooting, etc. We have a superuser, lets everything run with it!

1) There are some tricks to significantly reducing impact of
Spectre-like vulnerabilities, like disabling HT, separate processes to
run on different trust-level CPU core, KPTI, etc.
2) The kernel constantly reviewed, sure it is not an audit but some part
are well reviewed,  especially in general parts. The most vulnerable
parts are in the new features (in some we even do not realize the entire
possible impact), complex protocols like USB, WiFi, etc, the modules in
general.

I think it is worth reducing the attack surface. There were known
vulnerabilities in the perf kernel subsystem that allowed to escalate
privileges, and profiling is not a common task. I don't see why
switching the knob is a big problem.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Alexey Sheplyakov]

Hi,

On Sun, Jun 05, 2022 at 04:04:56PM +0300, Vladimir D. Seleznev wrote:
> > People who actually need security 
> > 
> > 1) don't use out-of-order CPUs (to avoid Meltdown, Spectre, etc)
> > 2) don't use Linux (so the kernel can be actually audited)
> > 3) don't exist
> 
> I don't get the point of these. If we don't need security why should we
> bother with user/group processes/filesystems separation and permissions,
> chrooting, etc. We have a superuser, lets everything run with it!

1. In a way we already do (on desktop systems). All applications run with
   the same uid and have the same permissions. Nothing prevents firefox
   from sending my private GPG key to $BIG_BROTHER, or removing all files
   (in $HOME), etc.
 
2. If you keep restricting the basic system functionality (profiling,
   namespaces, etc) to root only eventually people will be forced
   to run everything as root to get a usable system.

> 1) There are some tricks to significantly reducing impact of
> Spectre-like vulnerabilities, like disabling HT, separate processes to
> run on different trust-level CPU core, KPTI, etc.

> 2) The kernel constantly reviewed, sure it is not an audit but some part
> are well reviewed,  especially in general parts.

I'll just leave this here: https://lkml.org/lkml/2021/4/21/454

> I think it is worth reducing the attack surface.

There are a vast number of (privilege escalation) attacks which make
use of symlinks. Let's disable symlinks (for ordinary users).
And provide a magic knob (without any documentation) to re-enable them.

> There were known vulnerabilities in the perf kernel subsystem that 
> allowed to escalate privileges, 

There were known vulnerabilities in all kernel subsystem. Including
core ones, like mm (proofs: [1], [2], [3]). What about disabling CoW,
vmsplice, and other "insecure" stuff?

[1] https://lwn.net/Articles/849638 
[2] https://lwn.net/Articles/704231
[3] https://lwn.net/Articles/268783

> and profiling is not a common task.

Incorrect. Just because you don't care doesn't mean it's "not common".

> I don't see why switching the knob is a big problem.

The knob itself is not a big deal. The problem is the default value,
which prevents ordinary users from profiling their processes.


Best regards,
	Alexey

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

On Mon, 6 Jun 2022 13:20:40 +0400 Alexey Sheplyakov wrote:
> Hi,
> 
> On Sun, Jun 05, 2022 at 04:04:56PM +0300, Vladimir D. Seleznev wrote:
> > > People who actually need security 
> > > 
> > > 1) don't use out-of-order CPUs (to avoid Meltdown, Spectre, etc)
> > > 2) don't use Linux (so the kernel can be actually audited)
> > > 3) don't exist
> > 
> > I don't get the point of these. If we don't need security why should we
> > bother with user/group processes/filesystems separation and permissions,
> > chrooting, etc. We have a superuser, lets everything run with it!
> 
> 1. In a way we already do (on desktop systems). All applications run with
>    the same uid and have the same permissions. Nothing prevents firefox
>    from sending my private GPG key to $BIG_BROTHER, or removing all files
>    (in $HOME), etc.

Just use firejail.
  
Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Alexey Sheplyakov]

On Mon, Jun 06, 2022 at 01:31:04PM +0300, Andrey Savchenko wrote:
> On Mon, 6 Jun 2022 13:20:40 +0400 Alexey Sheplyakov wrote:
> > Hi,
> > 
> > On Sun, Jun 05, 2022 at 04:04:56PM +0300, Vladimir D. Seleznev wrote:
> > > > People who actually need security 
> > > > 
> > > > 1) don't use out-of-order CPUs (to avoid Meltdown, Spectre, etc)
> > > > 2) don't use Linux (so the kernel can be actually audited)
> > > > 3) don't exist
> > > 
> > > I don't get the point of these. If we don't need security why should we
> > > bother with user/group processes/filesystems separation and permissions,
> > > chrooting, etc. We have a superuser, lets everything run with it!
> > 
> > 1. In a way we already do (on desktop systems). All applications run with
> >    the same uid and have the same permissions. Nothing prevents firefox
> >    from sending my private GPG key to $BIG_BROTHER, or removing all files
> >    (in $HOME), etc.
> 
> Just use firejail.

You mean this one

https://unparalleled.eu/publications/2021/advisory-unpar-2021-0.txt ?

No, thanks.

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vladimir D. Seleznev]

On Mon, Jun 06, 2022 at 01:20:40PM +0400, Alexey Sheplyakov wrote:
> Hi,
> 
> On Sun, Jun 05, 2022 at 04:04:56PM +0300, Vladimir D. Seleznev wrote:
> > > People who actually need security 
> > > 
> > > 1) don't use out-of-order CPUs (to avoid Meltdown, Spectre, etc)
> > > 2) don't use Linux (so the kernel can be actually audited)
> > > 3) don't exist
> > 
> > I don't get the point of these. If we don't need security why should we
> > bother with user/group processes/filesystems separation and permissions,
> > chrooting, etc. We have a superuser, lets everything run with it!
> 
> 1. In a way we already do (on desktop systems). All applications run with
>    the same uid and have the same permissions. Nothing prevents firefox
>    from sending my private GPG key to $BIG_BROTHER, or removing all files
>    (in $HOME), etc.

I run firefox instanses and every semi-trusted applications with
different uids, so none of them can still my GPG or any other secrets or
corrupt my $HOME (until really bad things happen):

$ ps -eo uid,comm |grep firefox |uniq
 1022 firefox
 1032 firefox
 1020 firefox
 1036 firefox

> 2. If you keep restricting the basic system functionality (profiling,
>    namespaces, etc) to root only eventually people will be forced
>    to run everything as root to get a usable system.
> 
> > 1) There are some tricks to significantly reducing impact of
> > Spectre-like vulnerabilities, like disabling HT, separate processes to
> > run on different trust-level CPU core, KPTI, etc.
> 
> > 2) The kernel constantly reviewed, sure it is not an audit but some part
> > are well reviewed,  especially in general parts.
> 
> I'll just leave this here: https://lkml.org/lkml/2021/4/21/454

I read this. This just prove that these were not detected at submission
time, but in the end these were elicited.

> > I think it is worth reducing the attack surface.
> 
> There are a vast number of (privilege escalation) attacks which make
> use of symlinks. Let's disable symlinks (for ordinary users).

Some are mitigating with fs.protected_symlinks. But race conditions with
symlinks are about attacking userspace privilleged processes, not the
kernel.

> And provide a magic knob (without any documentation) to re-enable them.

Sure it should be documented.

> > There were known vulnerabilities in the perf kernel subsystem that 
> > allowed to escalate privileges, 
> 
> There were known vulnerabilities in all kernel subsystem. Including
> core ones, like mm (proofs: [1], [2], [3]). What about disabling CoW,
> vmsplice, and other "insecure" stuff?

Does it mean that we do not need to reduce attack surface because there
were (and will) vulnerabilities in the core subsystem?

> [1] https://lwn.net/Articles/849638 
> [2] https://lwn.net/Articles/704231
> [3] https://lwn.net/Articles/268783
> 
> > and profiling is not a common task.
> 
> Incorrect. Just because you don't care doesn't mean it's "not common".
> 
> > I don't see why switching the knob is a big problem.
> 
> The knob itself is not a big deal. The problem is the default value,
> which prevents ordinary users from profiling their processes.

Who is an ordinary user in your user model?

What kind of users exist? I distinguish several types of users (the list
is not intended to be exhaustive):

1. A homemaker or non-tech user that just uses a computer for
reading/writing documents, listening music, watch videos and browsing.
This kind of user does not need profiling.

2. A tech person who own personal computer, and this exactly person
admins her/his device. If he/her need profiling, he/her can easily
enable this feature.

3. A sysadmin who serves a lot of production servers. I think this type
is most targeted for this feature. Same as 2.

4. An ordinary user of big cluster, who can be a developer for such
system and who may need profiling. In that case he or her can ask the
cluster sysadmin to enable this feature.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vladimir D. Seleznev]

On Mon, Jun 06, 2022 at 03:54:00PM +0300, Vladimir D. Seleznev wrote:
> On Mon, Jun 06, 2022 at 01:20:40PM +0400, Alexey Sheplyakov wrote:
> > Hi,
> > 
> > On Sun, Jun 05, 2022 at 04:04:56PM +0300, Vladimir D. Seleznev wrote:
> > > > People who actually need security 
> > > > 
> > > > 1) don't use out-of-order CPUs (to avoid Meltdown, Spectre, etc)
> > > > 2) don't use Linux (so the kernel can be actually audited)
> > > > 3) don't exist
> > > 
> > > I don't get the point of these. If we don't need security why should we
> > > bother with user/group processes/filesystems separation and permissions,
> > > chrooting, etc. We have a superuser, lets everything run with it!
> > 
> > 1. In a way we already do (on desktop systems). All applications run with
> >    the same uid and have the same permissions. Nothing prevents firefox
> >    from sending my private GPG key to $BIG_BROTHER, or removing all files
> >    (in $HOME), etc.
> 
> I run firefox instanses and every semi-trusted applications with
> different uids, so none of them can still my GPG or any other secrets or
                                      ^ steal /* fixed */
> corrupt my $HOME (until really bad things happen):

-- 
   WBR,
   Vladimir D. Seleznev

Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Alexey Sheplyakov]

Hi again,

On Sun, Jun 05, 2022 at 10:59:11AM +0300, Dmitry V. Levin wrote:
> > Breaking a basic system functionality (such as debugging and profiling)
> > has nothing to do with security.
> 
> Whatever you might consider a basic system functionality is your point of
> view, other people are likely to have different use cases where some of
> things your treat as basic are redundant or even dangerous.

So what? There are people who think that open source software is inherently
dangerous (since everyone can examine the source and exploit bugs) and should
be banned. Some people think that computers are redundant or even dangerous.

> With regards to debugging and profiling, I do have installs where neither
                                          ^^^
> debugging nor profiling should be allowed, and we have 
                                                ^^^^
L’État c’est moi, huh?

> a universal kernel to achieve that.

Surely you can have whatever crazy setup (that's what open source is
about). However punishing everyone for that is not appreciated at all.

Happy hacking,
	Alexey

[d-kernel] right to profile (Re: [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open)

[Alexey Sheplyakov]

Hello,

On Mon, Jun 06, 2022 at 03:53:59PM +0300, Vladimir D. Seleznev wrote:

> > > I think it is worth reducing the attack surface.
> > 
> > There are a vast number of (privilege escalation) attacks which make
> > use of symlinks. Let's disable symlinks (for ordinary users).
> 
> Some are mitigating with fs.protected_symlinks. But race conditions with
> symlinks are about attacking userspace privilleged processes, not the
> kernel.

The result is the same: the attacker gains root access to the system.
And there've been *much* more symlink related attacks than the one based
on perf. So, should we disable symlinks by default?

> > And provide a magic knob (without any documentation) to re-enable them.
> 
> Sure it should be documented.
> 
> > > There were known vulnerabilities in the perf kernel subsystem that 
> > > allowed to escalate privileges, 
> > 
> > There were known vulnerabilities in all kernel subsystem. Including
> > core ones, like mm (proofs: [1], [2], [3]). What about disabling CoW,
> > vmsplice, and other "insecure" stuff?
> 
> Does it mean that we do not need to reduce attack surface because there
> were (and will) vulnerabilities in the core subsystem?

Most attempts to reduce it either make the system unusable (SELinux)
and/or end up *increasing* the attack surface (namespaces, SELinux)
via adding/exposing lots of complicated code (into kernel), extra suid
binaries, etc.

> What kind of users exist? I distinguish several types of users (the list
> is not intended to be exhaustive):
> 
> 1. A homemaker or non-tech user that just uses a computer for
> reading/writing documents, listening music, watch videos and browsing.
> This kind of user does not need profiling.

Wrong. These guys are exactly the ones who need profiling.
Profiling *on their* system is the only way to get meaningful
data from "my browser freezes when playing youtube videos"
(see https://bugzilla.altlinux.org/41486)
Now I can tell them to start their browser from terminal as

perf record -g firefox

> 2. A tech person who own personal computer, and this exactly person
> admins her/his device. If he/her need profiling, he/her can easily
> enable this feature.

Wrong. Those folks will install a differnt distro without a вахтёр syndrom.

> 3. A sysadmin who serves a lot of production servers.

This one is supposed to 
- know what perf is
- be able to figure out if running perf is a privacy/security
  concern (for a given workload)
- know how to uninstall/disable perf if necessary 
  
> 4. An ordinary user of big cluster, who can be a developer for such
> system and who may need profiling. In that case he or her can ask the
> cluster sysadmin to enable this feature.

Been there, done that (this partly explains why I'm so angry about
the patch). Those requests get redirected to /dev/null, because that's
the easiest thing to do for an admin. It takes a lot of time and effort
even to get the request considered, let alone implemented.

Best regards,
	Alexey

[d-kernel] [JT] Re: right to profile

[Michael Shigorin]

On Wed, Jun 08, 2022 at 06:27:26PM +0400, Alexey Sheplyakov wrote:
> > 2. A tech person who own personal computer, and this exactly
> > person admins her/his device. If he/her need profiling,
> > he/her can easily enable this feature.
> Wrong. Those folks will install a differnt distro without
> вахтёр syndrom.

Братцы, мне кажется, что в LDV Linux* достаточно давно есть
control(8) и если получается дополнительные ограничения
органично оформить соответствующей ручкой, то они приживаются;
в некоторых образах/шаблонах могут быть включены "из коробки",
в других -- нет, ну и у пользователей по вкусу.

К этому интерфейсу и для alterator модуль есть,
и в mkimage-profiles фича тоже.

* (c) led@

PS: см. тж. `rpm -q --scripts mkimage-preinstall` и заодно
http://www.opennet.ru/openforum/vsluhforumID3/101076.html#54

PPS: я могу попытаться писать по-немецки just for lulz,
но те, кто его *знает*, могут быть выведены из строя...

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info