From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 3 Jun 2022 18:07:55 +0300 From: Vitaly Chikunov To: ALT Linux kernel packages development Message-ID: <20220603150755.34lewntzb4ylbyel@altlinux.org> References: <20220602003100.524482-1-vt@altlinux.org> <20220602163914.GB11775@altlinux.org> <20220603092546.80db0c808ac37505e966d227@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20220603092546.80db0c808ac37505e966d227@altlinux.org> Subject: Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open X-BeenThere: devel-kernel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2022 15:07:55 -0000 Archived-At: List-Archive: List-Post: 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