The below change proposal was accidentally sent to the mailing list under a wrong name.
Below I copy/paste the original email from the change wrangler of 4 Sep 2025 6:58 p.m. with the correct subject given that the previous name might have been misleading (it might be useful to keep the discussion in the Discourse topic):
------------------------
Wiki:
https://fedoraproject.org/wiki/Changes/ptrace_scope_bpf_jit_harden
Discussion Thread:
https://discussion.fedoraproject.org/t/f44-change-proposal-ptrace-scope-bpf-...
**This is a proposed Change for Fedora Linux.**
This document represents a proposed Change. As part of the Changes
process,
proposals are publicly announced in order to receive community
feedback.
This proposal will only be implemented if approved by the Fedora
Engineering Steering Committee.
== Summary ==
This proposal aims to improve the security of Fedora and increase
its
resilience against attacks, including mitigating vulnerabilities
and
attacks that could be enabled by user behavior: targeting average
users as
of today, it is also our responsibility to implement measures to
preemptively protect users and predict that users, e.g., enable
third party
repos from unknown parties or manually install packages or drivers
that no
longer get updates or are not implemented by best practices, or
run scripts
that are not trustworthy: the protection we can offer here is
limited, but
the kernel ships with several means that are intended to offer
mitigation.
To avoid misunderstandings: these means are not just to mitigate
user-caused vulnerabilities/attacks but also to add additional
security
layers that can make a difference if others fail (e.g.,
vulnerabilities in
our packages).
Enable `kernel.yama.ptrace_scope`, `kernel.kptr_restrict` and
`net.core.bpf_jit_harden` by default in the kernel to increase the
security
of Fedora and mitigate some vulnerabilities and attacks.
`kernel.yama.ptrace_scope` is already enabled by default upstream,
but on
Fedora it is currently disabled by default because of a package
that
accidentally became a dependency for default installations.
Enable `ptrace_scope` at value `1` (kernel default `1`; or
consider `2` if
FESCo concludes this cannot cause issues), `kernel.kptr_restrict`
at value
`1` (or consider `2` if FESCo concludes this cannot cause issues)
and
`bpf_jit_harden` at `1` (or `2` if FESCo concludes this cannot
cause
issues). However, with regards to bpf_jit_harden, risks at `2`
might be
less predictable, and FESCo might be more careful before using
`2`: if
someone comes up with reproducible reasons why to not set `2` as
default or
if FESCo cannot exclude noteworthy amounts of bpf_jit activities
through
privileged users in some use cases (`2` = bpf_jit_harden is
imposed both on
privileged and unprivileged while `1` is imposed only on
unprivileged),
then `1` might be better for `bpf_jit_harden`: `bpf_jit_harden`
only risks
a performance decrease (respectively power-consumption increase)
and only
as far as it is used, but use cases of any of our targeted
audiences
involving privileged bpf_jit activities could be harder to
determine/predict (respectively more realistic to occur) than use
cases
with unprivileged bpf_jit activities.
Theoretically, `kernel.yama.ptrace_scope` is already at `1`, but
the
package `elfutils-default-yama-scope` overwrites this because it
accidentally became a default package: therefore, add this package
to [
https://src.fedoraproject.org/rpms/fedora-obsolete-packages
fedora-obsolete-packages] to ensure it is removed from all
installations on
their next update and then remove this package as dependency and
remove it
from the repository at all because the risk of accidentally
re-reinstall it
by default on Fedora installations remains, as we experience it at
the
moment. Further, it is common in the Fedora community, and
propagated among
users and supporters, to assume that installed tools/applications
"do not
hurt/impact" except using some space. This packages breaks with
this common
assumption and thus introduces further risks: `ptrace_scope` has
the
capacity to prevent malicious processes (e.g., vulnerable software
or
self-installed malicious software) to take control of other
processes or
their data.
Many Linux distributions keep `ptrace_scope` already by default
(e.g.,
Ubuntu, Arch Linux), as it is set by the upstream kernel, and
their users
seem to be satisfied to keep this default (value `1`, but also
consider `2`
for Fedora).
With regards to `bpf_jit_harden`, the Kernel Docs mention that
formally,
the settings `1` and `2` rather than `0` are performance
trade-offs, but I
could not identify a performance impact on my installation with
`2` (Arch
Linux already sets `2` by default in its hardened kernel) with
average
activities (surfing on the Internet/Firefox, watching movies in
browser and
vlc, editing/writing documents/code with
git/kate/kwrite/nano/mcedit,
emails, copying large amounts of files, working on battery,
Internet on
wifi & usb-ethernet), although as mentioned above, use cases
that are
impacted by `2` might be more realistic than `1` (FESCo might be
able to
evaluate this more reliably). Also, although Fedora and RHEL
differ in many
respects, it might be indicative that for security-sensitive RHEL
installations, `2` is already suggested for "bpf_jit_harden",
tested, and
partly required, by DISA (see Discussion topic mentioned below,
post #12,
which suggests that practical cases as far as known have not
identified
performance/power-consumption issues).
Further, set `kernel.kptr_restrict` to either `1` (`2` if FESCo
concludes
that this cannot cause negative impacts). Given its circumstances,
I could
not identify a negative impact that could affect one of our
targeted
audiences, although `2` might need a wider review by FESCo. This
means can
avoid the use of kernel exploits in some circumstances, and
although in our
case it could be possible that attackers might be able to mitigate
kptr_restrict, the level of experience will change: in some
circumstances,
using a kernel exploit can be as easy as a google search with
copy/paste,
and be taught early in average (online) pentesting courses. Yet,
the means
that become necessary in cases that are related to
`kptr_restrict`, deep
expert knowledge might become necessary to use an exploit, if
possible at
all.
Details about the settings and what they can mitigate are
elaborated in the
Kernel Docs and in the Arch Wiki (whose arguments in this respect
can be
transferred to Fedora): See documentation section below.
== Owner ==
* Name: [[User:py0xc3| py0xc3]]
* Email: py0xc3@xxxxxxxxxxxxxxxxx
== Detailed Description ==
The (security) advantages are best described in the links of the
summary
above (Arch Wiki & Kernel Docs links): the information is
concise and
comprehensible. For people without experience in this field, the
advantages
can be summed up as following: it increases the security by
mitigating
attacks/vulnerabilities -> especially if people modify their
system with
untrusted/unqualified suggestions found on the Internet, and
install
untrusted third party code (e.g., such code might not implement
best
practices nor satisfy QA, or not get updated for long when
installed
manually, or at the worst, being intentionally malicious), these
means
might mitigate negative impacts this could have '''as far as
attacks are
related to bpf_jit, kernel symbol addresses and ptrace'''. The
means also
add a security layer if packages of ours have vulnerabilities, and
can thus
mitigate exploitation in the time before we update.
I could not identify negative performance/power-consumption
impacts in
average activities (I - proposal owner - am testing all three
means
permanently in the setting `2` on my "production laptop" Fedora
since
04.08.2025) nor could I identify related experiences from others
(formally,
performance/power-consumption issues are possible at
`bpf_jit_harden`): as
far as tested, the performance seems to remain unchanged and I see
limited
space for unexpected issues, although it might be useful to review
feedback
of other users on the Change Proposal to identify if there are
circumstances in which this is different, especially on
bpf_jit_harden with
`2` (everyone is encouraged to test the settings on their system
& use
cases and give feedback while the Change Proposal is open). As
mentioned
above, for RHEL, the performance-related setting `bpf_jit_harden`
is
already suggested or required at `2` for some security-critical
installations without known issues.
Yet, it can be decided by FESCo to start with `1` if use cases of
targeted
audiences are anticipated that might be impacted negatively by `2`
in any
of the three settings. This proposal thus suggests to shift the
decision of
`1` or `2` in all three cases to FESCo: `2` if possible, `1` if
potential
for negatively-impacting cases can be identified. Starting with
`1`, then
verifying data, and then go to `2` in a second proposal 1 or 2
releases
after the next might be an alternative too.
With regards to `ptrace_scope`, it seems that developers engaging
in
debugging on lower abstraction layers might experience
`ptrace_scope` to
hinder their capability to attach tools like `gdb` or `strace` to
running
processes, but by default Fedora should not be set to a "debugging
mode"
(as we also do not boot our kernel by default in debugging mode,
for good
reasons), and it can be expected that people who engage in such
activities
will be able to identify how to temporarily or permanently disable
these
settings or to identify the relevant documentation if it exists:
documentation is the answer, which affected users in the past had
already
asked for in (and searched for before opening) the bugtickets¹
when `1` was
introduced to `ptrace_scope` as default in the first place.
However, rather
than providing documentation, the introduction of the package
`elfutils-default-yama-scope` took place and it became originally
a
dependency of tools like `gdb`, and its only purpose is to only
disable the
(theoretically defaulted) `ptrace_scope`. However, this is a
problematic
practice, it breaks with the average assumption many people work
with and
that they propagate (installed tools/applications do not
hurt/impact except
using some space), it might impose disabling security means on
several
users permanently without their knowledge (including those just
testing
`gdb` or comparable packages without removing them subsequently),
and it
leads to risks like the current issue: the package accidentally
becomes
defaulted on all Fedora installations.
Most users are unlikely to be aware of the security advantage of
these
functions and would not know that this could increase their
security and
mitigate some realistic attacks: the secure way should be by
default, and
people needing debuggers should be able to have proper
documentation
(Fedora documentation and Discourse are well ranked if users
search for
error messages with regards to Fedora) to adjust their system
themselves,
and also decide on themselves if they want these changes to be
temporarily
when they need them, or permanently.
Therefore, proper documentation should be provided, and I can
volunteer to
provide Docs pages (preferably one page in our Quick Docs'
troubleshooting
and a short sentence with a link to the first mentioned page in
the SELinux
troubleshooting section because many people expected this to be a
SELinux
issue; I will have to discuss this with the Docs team) and a
Discourse
topic that affected people might find when experiencing the issue
IF
affected developer(s)/users provide me with the names of the
affected tools
and the very error messages these tools output (and maybe also the
behaviors that might be relevant for documentation), which I need
to create
easy-to-find and expressive/useful Docs pages (also to be ranked
high in
search queries with error messages).
`kptr_restrict` is sufficiently covered in the summary and the
Documentation below, along with further information of the other
kernel
settings mentioned in this proposal.
¹ related bug tickets of 2015:
https://bugzilla.redhat.com/show_bug.cgi?id=1196825
https://bugzilla.redhat.com/show_bug.cgi?id=1209492
https://bugzilla.redhat.com/show_bug.cgi?id=1234951
https://bugzilla.redhat.com/show_bug.cgi?id=1250079
== Feedback ==
This Change Proposal started in the following discussion, which
contains
further considerations and feedback about it:
https://discussion.fedoraproject.org/t/increase-security-by-adjusting-kernel...
== Benefit to Fedora ==
Increased security / additional security layer with regards to
attacks/vulnerabilities related to `ptrace`, `kptr_restrict` and
`bpf_jit`.
These might mitigate some risks that inexperienced or incautious
users may
accidentally introduce to their systems themselves (to some extent
"social
vulnerabilities/causes"), and also mitigate vulnerabilities in our
own
packages.
== Scope ==
* Proposal owners:
The three kernel settings have to be changed, and the package
`elfutils-default-yama-scope` has to be added to
`fedora-obsolete-packages`
and subsequently removed from dependencies and the repositories at
all in
order to enable `ptrace_scope` again in a reliable manner. I can
create the
Merge Requests for creating+installing the kernel settings through
systemd
and to add the mentioned package to the obsoleted ones, but I
might need
support to finally remove the package from our repositories with
its
dependencies as I expect I will not have privileges to achieve
that: in
finally removing the package from being available in Fedora
installations,
necessary support is likely to go beyond just accepting my MR in a
git
repository.
* Other developers:
Informing RelEng could be useful, but I expect there is no need
for them to
act (except their involvement is necessary to remove the package).
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
Provide an operating system for average users that is as secure by
default
as possible, not requiring users to setup their security means
themselves
and providing as far as possible preventive measures to mitigate
negative
impacts (up to preventing/mitigating user-caused
vulnerabilities/issues
when possible), but also to ensure additional security layers in
case,
e.g., vulnerabilities come up in packages of ours (the more time
it takes
to identify and solve a vulnerability once it occurred, the more
useful are
additional security layers that can mitigate attacks/exploitation
in some
circumstances).
Because we want to provide an operating system for average users /
for
everybody, we also have to consider and mitigate issues that are
made by
inexperienced or incautious users as far as this is possible
without
noteworthy negative impact. Surely everything remains a
compromise.
== Upgrade/compatibility impact ==
== Early Testing (Optional) ==
See the How To Test section.
== How To Test ==
Enable all three settings and work with it, and feel free to
exchange
results. An easy means to keep testing it permanently is to append
three
lines to the file `/etc/sysctl.conf`, in order to ensure the
settings are
set automatically on boot:
Values for lowest proposed changes:
<pre>
net.core.bpf_jit_harden = 1
kernel.yama.ptrace_scope = 1
kernel.kptr_restrict = 1
</pre>
Values for highest proposed changes:
<pre>
net.core.bpf_jit_harden = 2
kernel.yama.ptrace_scope = 2
kernel.kptr_restrict = 2
</pre>
You may want to test it temporarily at first, which means that it
shall not
persist when you shutdown/reboot your machine: you can achieve
that with
the sysctl command, e.g., these three commands are to set all
three to "2":
<pre>
sysctl net.core.bpf_jit_harden=2
</pre>
<pre>
sysctl kernel.yama.ptrace_scope=2
</pre>
<pre>
sysctl kernel.kptr_restrict=2
</pre>
The same commands can be used to set back your defaults without
rebooting.
You can verify the current settings with the following commands
(including
your system's defaults when you use these commands before using
any of the
above):
<pre>
cat /proc/sys/kernel/yama/ptrace_scope
</pre>
<pre>
cat /proc/sys/kernel/kptr_restrict
</pre>
<pre>
sudo cat /proc/sys/net/core/bpf_jit_harden
</pre>
(bpf_jit_harden needs sudo permissions)
'''Please do not test ptrace_scope with the setting `3` unless you
read
about its implications''', as the implications differ to `1` and
`2`. I
expect `3` is not relevant for Fedora.
== User Experience ==
Except for people who aim to debug running applications by
attaching tools
like `gdb` or `strace`, there should be no measurable/perceived
impact,
although my earlier elaborations should be considered.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Should not apply because this is just
enabling
three kernel settings. If any issue comes up that endangers the
release,
the maintainers/FESCo/RelEng can revert the three settings to the
earlier
defaults (`0`). The same for the package.
* Contingency deadline: to be set by FESCo/RelEng
* Blocks release? No: if issues come up with any of the three
settings,
they should be reverted to the earlier default rather than
blocking a
release.
== Documentation ==
'''kernel.yama.ptrace_scope:'''
https://wiki.archlinux.org/title/Security#ptrace_scope
https://docs.kernel.org/admin-guide/LSM/Yama.html
'''net.core.bpf_jit_harden:'''
https://wiki.archlinux.org/title/Security#BPF_hardening
https://docs.kernel.org/admin-guide/sysctl/net.html
https://docs.cilium.io/en/latest/reference-guides/bpf/architecture/#hardenin...
'''kernel.kptr_restrict:'''
https://wiki.archlinux.org/title/Security#Restricting_access_to_kernel_point...
https://docs.kernel.org/admin-guide/sysctl/kernel.html#kptr-restrict
'''Related to all three:'''
https://discussion.fedoraproject.org/t/increase-security-by-adjusting-kernel...
== Release Notes ==
Kernel setting `net.core.bpf_jit_harden` changed from `0` to `2`
and kernel
setting `kernel.yama.ptrace_scope` changed to from `1` to `2` and
kernel
setting `kernel.kptr_restrict` changed from `0` to `2`. This aims
to
increase security and mitigate vulnerabilities/attacks related to
`ptrace`,
`kernel symbol addresses` (potential for kernel exploits) and
`bpf_jit`.
For details, review the Change Proposal and its mentioned sources
(especially the related Kernel Docs). Further, the package
`elfutils-default-yama-scope` is obsoleted and removed from the
repository
to avoid the security means `kernel.yama.ptrace_scope` to get
accidentally
disabled again.
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
