From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 Date: Wed, 8 Jun 2022 18:27:26 +0400 From: Alexey Sheplyakov To: ALT Linux kernel packages development Message-ID: References: <20220602003100.524482-1-vt@altlinux.org> <20220602163914.GB11775@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: [d-kernel] right to profile (Re: [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: Wed, 08 Jun 2022 14:27:45 -0000 Archived-At: List-Archive: List-Post: 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