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 > > > > > > > > > > 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 > > > > > Signed-off-by: Tim Gardner > > > > > [ saf: resolve conflicts with v5.8-rc1 ] > > > > > Signed-off-by: Seth Forshee > > > > > [ vt: Make it default y. ] > > > > > Signed-off-by: Vitaly Chikunov > > > > > --- > > > > > 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