I re-send this to the mailing list with the correct subject for the discussion, but I suggest to read the proposal in Discourse [1] or in the wiki [2], as the AI that was used in the Change Wrangler process introduced changes beyond formatting, and so I cannot say for sure if this content is still identical to my proposal. A FESCo ticket about the AI issue is already opened - not relevant for here.
Since this has already been discussed many times, I presume the title and the summary suffice for the devel mailing list anyway :) [1] https://discussion.fedoraproject.org/t/f44-change-proposal-restrict-ptrace-for-unprivileged-users-to-child-processes-to-match-kernel-default-systemwide/174493 [2] https://fedoraproject.org/wiki/Changes/Restrict_ptrace_for_unprivileged_users_to_child_processes_to_match_kernel_default -------- Forwarded Message -------- Subject: Change Proposal: Restrict_ptrace_for_unprivileged_users_to_child_processes_to_match_kernel_default [SystemWide] Date: Tue, 25 Nov 2025 08:52:19 -0500 From: Allison King via devel-announce <[email protected]> Reply-To: [email protected] To: [email protected] CC: Allison King <[email protected]> Wiki: https://fedoraproject.org/wiki/Changes/Restrict_ptrace_for_unprivileged_users_to_child_processes_to_match_kernel_default Discussion Thread: https://discussion.fedoraproject.org/t/174493 **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 == The package elfutils-default-yama-scope will be removed in order to system-wide set `kernel.yama.ptrace_scope` to the kernel default `1` (like ArchLinux,openSuSE,Ubuntu,...), enabling `ptrace_scope` to mitigate attack vectors that can rise through vulnerable/untrusted/unupdated software/packages or user actions. If preferred, users can temporarily or permanently disable `ptrace_scope` with one command. To raise awareness and allow users more easily to further decrease potential for attack vectors if they want it, the file `10-harden-yama-ptrace.conf` (containing `kernel.yama.ptrace_scope = 2` and references/links with a short elaboration) will be added to [https://src.fedoraproject.org/rpms/systemd/tree/rawhide systemd] and added to systemd.spec (line `Source27: 10-harden-yama-ptrace.conf`), but NOT enabled/installed by default. == Owner == * Name: [[User:py0xc3| py0xc3]] * Email: [email protected] == Detailed Description == '''Background of kernel.yama.ptrace_scope in general and on Fedora:''' About 10 years ago the upstream kernel community enabled the function `kernel.yama.ptrace_scope` by default with the setting `1` in order to increase user protection against processes that are vulnerable or malicious and thus might be used to access/steal data from other processes (e.g., steal credentials and other private data from the Firefox process while its, e.g., passwords are unencrypted in the process's memory). See documentation below for links to technical documentation of `kernel.yama.ptrace_scope` (kernel docs & arch wiki). Especially on Fedora many user groups we target as users, and to whom we actively market Fedora, might be prone to the need to enable third-party repositories or install software manually (without considering implications about the source or without considering that manual installations do not get any updates automatically at all). Also, given the complexity and workload to maintain packages, Fedora repositories are not resilient against packages that accidentally get not updated for longer periods as well. However, the setting was disabled shortly after its introduction because it broke tools like `gdb` and `strace`, which are used by software developers to analyze other processes (e.g., to identify bugs). Nevertheless, the bug tickets (see documentation) of back then show that developers experiencing the issue were searching documentation of the issue rather than asking for disabling the function. Compared to the introduction through the upstream community back then, we can provide sufficient documentation & provision of information for Fedora users this time: most important might be expressive release notes and keeping `gdb` and `strace` (and other) maintainers informed to handle bug tickets appropriately and without wasting time. Fedora should emphasize security by default rather than disabling a security feature like this for all. Even for software developers affected by this, we cannot determine for sure if all of them want this feature to be disabled permanently: we can expect software developers working with such tools to end up either at release notes or in (self-created) bug tickets at the tools' maintainers. We should provide all means to allow affected users to quickly identify and solve the issue for their very use case / situation, but the decision which mitigation to use should remain theirs, tailored to their very circumstances. ''' Raising awareness and simplifying the enabling of ptrace_scope setting `2` without installing/enabling it by default:''' Raising awareness for the ptrace_scope setting `2` and simplifying its enabling process (see summary) might be useful for some users with a related security interest, who might not become aware or capable of implementing this otherwise (it also simplifies Docs pages that refer to that means & how to enable it for those interested). While this will not make a major difference for most use cases, it will have no user impact on itself: the file for enabling ptrace_scope with `2` NOT be enabled/installed by default, but only added to systemd so that users can enable it manually. --------------------------------------- See the documentation in the Kernel Docs and Arch Wiki for technical details along with the two devel mailing list discussions (links in the "documentation" section of this proposal). --------------------------------------- '''Mitigations for users affected by this change in a negative way:''' While one command can temporarily disable ptrace_scope easily (e.g., `sysctl kernel.yama.ptrace_scope=0`; see "How To Test" section for details), Fedora is already shipped with a standardized way to also disable ptrace_scope permanently for those who prefer it that way (see the "Docs pages as mitigation" sub-section below or the suggested release notes below for information about the file `/usr/share/doc/systemd/20-yama-ptrace.conf`, or review the file on your system or in the [https://src.fedoraproject.org/rpms/systemd/tree/rawhide systemd] repo). Permanently disabling ptrace_scope can be done by one command as well. First, the proposal owner will keep the maintainers of `gdb` and `strace` (the package maintainer reported this to also affect `valgrind vgdb`/`eu-stack`/`elfutils libdw`, whose maintainers will be informed as well) informed about this feature and provide the means to mitigate its impact in order to avoid that bug tickets waste their time and that bug tickets get resolved immediately with a short copy/paste-like response containing the details of the release notes or Docs reference. Given that 10 years ago several users thought this to be a SELinux-related issue, the owner will also inform the selinux-policy maintainer about this before its actual introduction. The proposal owner would be open to handle such tickets if the maintainers choose to involve him. Several software developers already replied in the earlier proposal that the release notes will make a difference for them if they are expressive: the below release notes are aligned with their feedback. '''Docs pages as mitigation for users affected by this change, if developers want it and provide some data:''' As promised in an earlier discussion, the change owner will be happy to implement Docs pages for the affected software developers: the earlier bug tickets of 2015 [3] indicate that affected developers were seeking related Docs pages, and some also checked out SELinux troubleshooting (assuming this is SELinux related): it is already agreed with the Docs team that we can create a gdb/strace troubleshooting page and add a reference about this issue to the SELinux troubleshooting page. However, due to a lack of time & lack of the perspective of the affected user group, the change owner depends on affected users (= regular `gdb`/`strace` users) to provide the raw data to him for the dedicated gdb/strace troubleshooting Docs page: no Docs-specific formatting or Docs-specific preparations needed, but the raw content needs to be there if this mitigation is wanted (sufficient & clear elaboration of the issue from a developer's perspective, error outputs, other implications relevant for developers; the solution can be already contained but the change owner can also add a section himself elaborating the intended solution though the temporary sysctl command or the existing `20-yama-ptrace.conf` that just needs to be enabled with systemd for permanent disabling of ptrace_scope). A section with short elaboration and reference to the gdb/strace troubleshooting within the SELinux troubleshooting page will then be created by the proposal owner as well if the gdb/strace troubleshooting page is implemented. If the Docs pages are created, and given the increased use of Discourse and its well search-engine optimization, the owner will also provide a Discourse topic in ask.fedora with a solution that links to the Docs pages. On the long term, community members who regularly use `gdb`/`strace` have already mentioned interest in contributing to `gdb` and `strace` to make the tools to immediately output appropriate information when impacted by ptrace_scope, but so far no one can predict when they will have time: so this cannot be considered/guaranteed at this time. == Feedback == This proposal considers the feedback from many users, software developers (including regular `gdb`/`strace` users of the community) and FESCo members, but also was presented about 4 weeks before publishing to the Fedora maintainers of `gdb` and `strace`. Feedback has been considered as far as provided. An exchange with an `elfutils-default-yama-scope` maintainer took place, while their preference is to keep the `elfutils-default-yama-scope` package the way it is. They added their points to the feedback section, which I quote as they wrote it: (begin citation) -------------------------------------------
/No investigation has been done which other tools (eu-stack, valgrind
vgdb, elfutils-libs users) are broken by this change. Fedora isn't a user appliance distro, but one that encourages admins to become developers. So it should not have observability (profilers, debuggers, tracers, etc.) tools broken out of the box. Enabling these tools would require running commands as root. This is probably a bigger security risk. Running these tools as root should be discouraged. Why not look for a solution where user space keeps working by default, but some system calls/proc file system usage might be disabled if the system doesn't install certain admin and developer tools (e.g. some yama-scope package depenencies are fixed or moved from Required to Suggested)? In general it does seem that adding yama support is a somewhat broken approach for what you seem to want since it impacts user space globally. It is a "solution" if you want to restrict users so they cannot easily admin or develop their systems, making them hard to observe. Other LSMs provide mechanisms to implement a real policy. Yama only provides one global on/of like switch. Maybe adjust yama to have a more flexible policy and/or look into an selinux based policy?/ ------------------------------------------- (end citation) The proposal owner confirms that no investigation specific to tools like eu-stack etc. has been done, but refers to the vast feedback before, during and after the first proposal including much feedback from users of affected tools (see documentation), and the conclusion that can be drawn from Arch Linux, OpenSuSE and Ubuntu, who did not disable ptrace_scope in the 10 years in which it has been kernel default. With regards to using SELinux to achieve the outcome of ptrace_scope: this would relate to SELinux's "confined users", and the Security SIG and Confined Users SIG have been working on this for 2 years. Yet, confining user accounts by default would break a lot, and it would bring widespread changes in the behaviors especially within graphical user accounts (e.g., cockpit regularly breaks after updates when SELinux-confinement is enabled; Firefox video conferencing remains broken for long). Many maintainers would have to permanently consider this in their actions and continuously contribute in order to make a confined user account work by default. Flatpak remains effectively broken in confined user accounts as well. Therefore, the proposal owner dismissed this possibility due to high risks of regular denials of service. If other tools like `gdb`, `strace`, (and `valgrind vgdb`, `eu-stack`, `elfutils libdw`) are around that are affected, feel free to inform the change owner so that he can inform these tools' maintainers before the introduction along with the `gdb`/`strace` maintainers. == Benefit to Fedora == Users, especially average users, who often depend on introducing third party software without knowing all implications of third party repositories or manual installations and implications around sources of the code they introduce, will have more security by default: processes are better isolated from each other, which mitigates impacts from packages that are vulnerable, malicious or not updated/maintained for long. Also, Fedora aligns closer with the upstream kernel (and its behaviors) and with other Linux distributions that already use this change for long, adopting what is already a de-facto-standard. With regards to raising awareness and simplifying to set ptrace_scope to `2`, users (who have an interest to increase their security by reducing potential for related attack vectors) might become more likely aware of it, and have a simplified means to implement it. This also simplifies providing Docs pages about ptrace_scope with `2`. == Scope == * Proposal owners: For the setting `1`, the owner's activities would be limited to providing the mentioned means for mitigation, and support in removing the package `elfutils-default-yama-scope` as far as that is possible / useful. For the setting `2` (which will not be installed/enabled by default), the owner will provide the pull request for [ https://src.fedoraproject.org/rpms/systemd/tree/rawhide systemd] (see summary section for the content of the pull request). * Other developers: Support will be necessary to remove the package `elfutils-default-yama-scope` from other packages' dependencies and from the repositories at all. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] -> Exchanging with RelEng might be useful to coordinate the introduction of the feature in the very release, but they do not need to consider this feature beyond knowing that it has to be added. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Fedora actively targets and markets its OS towards average users. This means we take the responsibility to anticipate the mistakes of average users and mitigate them as far as possible, especially as the lack of (patented and other) packages on Fedora might make them more prone (compared to other Linux distributions) to install third-party repositories or software (e.g., manual installation of software that will never be updated or is vulnerable/malicious at all) without understanding all implications. Most other Linux distributions do this already with ptrace_scope being set to `1`. This proposal also aligns with "security by default" and the current strategy's goal to improve security. == Upgrade/compatibility impact == The settings should be updated also on installations with earlier Fedora releases when they 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: on one hand, given that it can break work flows temporarily for gdb/strace users, they are likely to be prepared to spend some time to tackle some issue on an upgrade rather than being surprised after a daily update. On the other hand, if the issue occurs after a release upgrade, developers are more likely to check the release notes and consider this to be linked to a new feature rather than immediately anticipating a bug (there is feedback from software developers in the earlier proposal confirming this). == How To Test == Testing the kernel default of ptrace_scope (`1` & `2`) is easy and it can be done temporarily (reset to the package's ptrace_scope=`0` after reboot) or permanently by several means. The easiest and for now most transparent ways are the following: Temporarily: `sysctl kernel.yama.ptrace_scope=1` (as long as the package is installed, it will be reset to `0` after rebooting) Permanently: `echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.conf` (while the package overrides the kernel default, this line will subsequently override the value set by the package: this can be undone just by removing the line again from `/etc/sysctl.conf`). If the setting `2` is to be tested, just replace the `1` in the above commands with `2` (this change proposal will NOT enable/install `2` by default!). The very value of ptrace_scope can be checked / verified at all times with `cat /proc/sys/kernel/yama/ptrace_scope` '''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: the setting `1` is well understood through most Linux distributions already using it by default for about 10 years (e.g., openSuSE, Arch Linux, Ubuntu). With regards to raising awareness and simplifying to set ptrace_scope to `2`, users (who have an interest to increase their security by reducing potential for related attack vectors) might become more likely aware of it, and have a simplified means to implement it. This also simplifies providing Docs pages about ptrace_scope with `2`. This change should decrease the likelihood that people experience attacks / exploitations of vulnerabilities / stealing of data related to ptrace. == Dependencies == There are no technical or package dependencies. But the owner depends on others to remove the package `elfutils-default-yama-scope` from the repositories. == Contingency Plan == * Contingency mechanism: if the feature cannot be implemented on time, it can just be postponed to the then-next release. * Contingency deadline: to be determined by FESCo/RelEng * Blocks release? No. == Documentation == '''kernel.yama.ptrace_scope:''' https://wiki.archlinux.org/title/Security#ptrace_scope https://docs.kernel.org/admin-guide/LSM/Yama.html '''Earlier related discussions before and during the first proposal:''' https://lists.fedoraproject.org/archives/list/[email protected]/thread/HP6BYUBCD73XM2ZOMGUH2W7K6XQCXXVC/ (most recent discussion in devel mailing list) https://lists.fedoraproject.org/archives/list/[email protected]/thread/URIJ7JZQX63MVLMEWKP5NF6AFXI2BXHI/#URIJ7JZQX63MVLMEWKP5NF6AFXI2BXHI (devel mailing list discussion of preceding, withdrawn proposal) https://discussion.fedoraproject.org/t/f44-change-proposal-mitigate-vulnerabilities-attacks-by-enabling-kernel-kptr-restrict-and-net-core-bpf-jit-harden-by-default-and-by-obsoleting-a-package-that-risks-to-accidentally-disable-kernel-yama-ptrace-scope-by-default-systemwide/163535 (discourse discussion of preceding, withdrawn proposal) 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 (discourse discussion of the time before the preceding, withdrawn proposal) '''Agreement with Docs team & elaboration of proposed Docs pages:''' https://discussion.fedoraproject.org/t/new-quick-docs-page-necessary-for-change-proposal-upstream-kernel-change-will-cause-issues-to-debuggers/163931 '''Bug tickets of 2015 documenting parts of the issue handling that lead to the original disabling of `kernel.yama.ptrace_scope` after it was enabled by the upstream kernel:''' 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 == Release Notes == If the package is removed & ptrace_scope set to the kernel default, the Fedora release no longer containing this package should contain the following in the release notes if the Docs pages are implemented: ''The security-relevant kernel setting `kernel.yama.ptrace_scope` is reset from `0` to the kernel default `1` (see [ https://docs.kernel.org/admin-guide/LSM/Yama.html upstream Docs of the setting]) through removing the package `elfutils-default-yama-scope`: kernel.yama.ptrace_scope can break some functions of tools like gdb or strace (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.'' An alternative if the Docs pages are not implemented, is: ''The security-relevant kernel setting `kernel.yama.ptrace_scope` is reset from `0` to the kernel default `1` (see [ https://docs.kernel.org/admin-guide/LSM/Yama.html upstream Docs of the setting]) through removing the package `elfutils-default-yama-scope`: kernel.yama.ptrace_scope can break some functions of tools like gdb or strace (debugger tools) if the functions are related to attaching the tool to other processes. It might be necessary to disable kernel.yama.ptrace_scope temporarily when attaching gdb or other tools to processes that are not child processes with `sysctl kernel.yama.ptrace_scope=0` (default is 1, undone automatically after reboot). Permanent disabling is possible as well (read the file `/usr/share/doc/systemd/20-yama-ptrace.conf` for instructions), but keep in mind that this is an important security function to protect processes and contained data.''
-- _______________________________________________ devel-announce mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
