From: Alexey Sheplyakov <asheplyakov@basealt.ru> To: ALT Linux kernel packages development <devel-kernel@lists.altlinux.org> Subject: [d-kernel] right to profile (Re: [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open) Date: Wed, 8 Jun 2022 18:27:26 +0400 Message-ID: <YqCxzvmQmlXsaG03@asheplyakov-rocket> (raw) In-Reply-To: <Yp3453iEeYPzZpEM@portlab> 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
next prev parent reply other threads:[~2022-06-08 14:27 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-02 0:31 [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open Vitaly Chikunov 2022-06-02 7:14 ` Dmitry V. Levin 2022-06-02 12:40 ` Vitaly Chikunov 2022-06-02 13:29 ` Vitaly Chikunov 2022-06-02 15:58 ` Andrey Savchenko 2022-06-02 17:06 ` Vitaly Chikunov 2022-06-02 18:26 ` Vladimir D. Seleznev 2022-06-02 18:42 ` Andrey Savchenko 2022-06-02 18:56 ` Dmitry V. Levin 2022-06-03 6:27 ` Andrey Savchenko 2022-06-02 19:08 ` Vladimir D. Seleznev 2022-06-03 6:16 ` Andrey Savchenko 2022-06-03 12:41 ` Vladimir D. Seleznev 2022-06-03 12:54 ` Andrey Savchenko 2022-06-02 15:15 ` Alexey Sheplyakov 2022-06-02 16:39 ` Dmitry V. Levin 2022-06-03 6:25 ` Andrey Savchenko 2022-06-03 15:07 ` Vitaly Chikunov 2022-06-05 7:48 ` Alexey Sheplyakov 2022-06-05 7:59 ` Dmitry V. Levin 2022-06-06 14:31 ` Alexey Sheplyakov 2022-06-05 13:04 ` Vladimir D. Seleznev 2022-06-06 9:20 ` Alexey Sheplyakov 2022-06-06 10:31 ` Andrey Savchenko 2022-06-06 12:10 ` Alexey Sheplyakov 2022-06-06 12:53 ` Vladimir D. Seleznev 2022-06-06 12:59 ` Vladimir D. Seleznev 2022-06-08 14:27 ` Alexey Sheplyakov [this message] 2022-06-15 11:19 ` [d-kernel] [JT] Re: right to profile Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YqCxzvmQmlXsaG03@asheplyakov-rocket \ --to=asheplyakov@basealt.ru \ --cc=devel-kernel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git