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