Wiki: https://fedoraproject.org/wiki/Changes/ptrace_scope_bpf_jit_harden
Discussion Thread: https://discussion.fedoraproject.org/t/f44-change-proposal-ptrace-scope-bpf-jit-harden-systemwide-ptrace-scope-bpf-jit-harden-systemwide/163535
**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@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.
* 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/#hardening
'''kernel.kptr_restrict:'''
https://wiki.archlinux.org/title/Security#Restricting_access_to_kernel_pointers_in_the_proc_filesystem
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-settings-by-default-kernel-yama-ptrace-scope-net-core-bpf-jit-harden-both-defaulting-to-1/161498/
== 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.
-- Discussion Thread: https://discussion.fedoraproject.org/t/f44-change-proposal-ptrace-scope-bpf-jit-harden-systemwide-ptrace-scope-bpf-jit-harden-systemwide/163535
**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@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.
* 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/#hardening
'''kernel.kptr_restrict:'''
https://wiki.archlinux.org/title/Security#Restricting_access_to_kernel_pointers_in_the_proc_filesystem
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-settings-by-default-kernel-yama-ptrace-scope-net-core-bpf-jit-harden-both-defaulting-to-1/161498/
== 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.
No comments:
Post a Comment