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 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, openSuSE), 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: py0xc3
-
Email: py0xc3@fedoraproject.org
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-settings-by-default-kernel-yama-ptrace-scope-net-core-bpf-jit-harden-both-defaulting-to-1/161498/
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.
Concerning changing the kernel settings: I will add a file 20-kptr_restrict.conf and 20-core-bpf_jit_harden to Tree - rpms/systemd - src.fedoraproject.org , add the files with Source entries to systemd.spec and then enable the Source entries to be installed by default. Additionally, if FESCo agrees to also set ptrace_scope to 2 rather than the upstream kernel default, I will replace the content of the file 20-yama-ptrace.conf to set 2 rather than 0 (and remove its current comments) and add its Source entry to be installed by default, but in this case, I would also create the file 30-yama-ptrace.conf for 0 with the content of the current 20-yama-ptrace.conf, and I would also add a reference to 20-yama-ptrace.conf about 30-yama-ptrace.conf, so that developers who need to debug retain their means for quickly disabling ptrace_scope and to have a way of disabling ptrace_scope that can be added to potential documentations. 30-yama-ptrace.conf would not be installed by default. If I am provided with the means to create the documentation (see above), then I would use 30-yama-ptrace.conf for elaborating how to disable ptrace_scope permanently by default.
- Other developers:
There are no other developers: although system-wide, this proposal is in the end just changing three settings that should not cause further work once implemented. After that, it is work as usual: everybody who has an issue opens a bugzilla ticket once applicable, and related maintainers get informed / take over, and I will be happy to get involved if something seems to be related to my proposal. If in the aftermath problems rise with this proposalâs changes, and if FESCo considers thus to undo it (or to change any 2 to a 1), then if necessary I can do the revert if FESCo wants me to do it, although I consider undoing it unlikely to become necessary. If the need to further improve documentation comes up (add tools and error messages to documentation not considered earlier along with the solution to solve the issue), I am happy to do so, and maintainers/users/developers of bugtickets are free to reach out to let me know about the need - although as mentioned above: I need the data/information provided that is necessary to prepare/provide the documentation.
- Release engineering: #Releng issue number
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).
-
Policies and guidelines: N/A (not needed for this Change)
-
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
The settings should be updated also when earlier Fedora releases are upgraded to the release of this proposal. So it should not only be the default for new installations, but also for upgraded installations. However, it might be more stable/secure to introduce it only to installations that are upgraded to the next release (or installed with the next release), but not introduced through normal âdailyâ updates within earlier releases.
Early Testing (Optional)
See the How To Test section.
Do you require âQA Blueprintâ support? N
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:
net.core.bpf_jit_harden = 1
kernel.yama.ptrace_scope = 1
kernel.kptr_restrict = 1
Values for highest proposed changes:
net.core.bpf_jit_harden = 2
kernel.yama.ptrace_scope = 2
kernel.kptr_restrict = 2
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â:
sysctl net.core.bpf_jit_harden=2
sysctl kernel.yama.ptrace_scope=2
sysctl kernel.kptr_restrict=2
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):
cat /proc/sys/kernel/yama/ptrace_scope
cat /proc/sys/kernel/kptr_restrict
sudo cat /proc/sys/net/core/bpf_jit_harden
(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.
This change should decrease the likelihood that people experience attacks / exploitations of vulnerabilities related to ptrace and bpf_jit or kernel symbolic addresses (the latter is related to kernel exploits)
Dependencies
None, although the package is a dependency of some other packages, but it can just be removed from their dependencies as it does nothing but disabling ptrace_scope.
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/#hardening
kernel.kptr_restrict:
https://docs.kernel.org/admin-guide/sysctl/kernel.html#kptr-restrict
Related to all three:
Release Notes
This change essentially achieves the adjustment of three kernel settings:
-
Kernel setting
net.core.bpf_jit_hardenchanged from0to2(see upstream Docs of the setting), -
kernel setting
kernel.yama.ptrace_scopechanged to from0(formally it was1but a package changed it to0by default on each boot in earlier releases) to2(see upstream Docs of the setting) and -
kernel setting
kernel.kptr_restrictchanged from0to2(see upstream Docs of the setting).
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.
kernel.yama.ptrace_scope can break some functions of tools like gdb or strace (mostly debugger tools) if the functions are related to attaching the tool to other processes. Documentation to mitigate the debugger issues is provided in the Quick Docsâ âTroubleshootingâ section: it might be necessary to disable kernel.yama.ptrace_scope temporarily or permanently when attaching gdb or other tools to processes, depending on user preferences. Keep in mind that this is an important security function to protect processes and contained data.
Last edited by @py0xc3 2025-09-12T09:15:38Z
Last edited by @py0xc3 2025-09-12T09:15:38Z
instead of reiterating. You can even do this by email, by replying with the heart emoji or just â+1â. This will make long topics easier to follow.
So cases in which it can be assumed that 1 solves the issue at all while 2 does not because if 1 solves it just sometimes, the issue is there anyway and the person is likely to either use good practice and solve the problem themselves (for which we provide documentation then), or get used to bad practices and just go sudo once sometimes does not work.