Implementing feedback from the Discourse thread, I already updated the proposal
[1]. This includes removing the possibility for enabling the ptrace_scope
setting `2` by default (now the proposal is only about enabling the kernel
default setting `1` of ptrace_scope by default) and also shortening the name of
the proposal: I will change the URL as well before submitting, but for now I
leave the page existing to avoid confusion, but keep in mind that the new name
is no longer corresponding to the URL but is simply this:
> Change kernel.yama.ptrace_scope to match kernel defaults (mitigates some
attack vectors)
[1]
https://discussion.fedoraproject.org/t/new-proposal-about-kernel-yama-ptrace-scope-two-perspectives-on-this-case-im-open-to-suggestions/172815/8
On 16/11/2025 12.35, Christopher Klooz wrote:
Hi,
I was asked to put this proposal once to discussion in the community before
officially submitting it:
https://fedoraproject.org/wiki/Changes/Enable_%22kernel.yama.ptrace_scope%22_by_default_to_adopt_upstream_kernel_default_(or_a_more_restrictive_setting_if_unforeseen_impact_is_unrealistic)_to_mitigate_attacks/impacts_due_to_malicious,_vulnerable_or_unmaintained/unupdated_packages/processes
It is the successor of an earlier proposal that included
kernel.yama.ptrace_scope that was withdrawn. Given the wide support of
ptrace_scope in the first proposal and its (imho) advantages, I wanted to
re-propose the ptrace_scope-related part of the withdrawn proposal early, and
in compliance to the suggestions of splitting it from the other changes.
Keep in mind that there has been already a discussion that was to large amounts
about ptrace_scope, and it might be useful to review it to avoid repeating
discussions that took already place:
https://lists.fedoraproject.org/archives/list/[email protected]/thread/URIJ7JZQX63MVLMEWKP5NF6AFXI2BXHI/#URIJ7JZQX63MVLMEWKP5NF6AFXI2BXHI
I think the two types of reasoning/opinions on this case can be summed up that
way (see also the feedback section of the proposal draft for a 1:1 summary of
the opinion A):
A) Tools/Applications should work by default for all, to motivate users to dive
deeper into Fedora, and thus become more likely effective contributors:
kernel.yama.ptrace_scope=1/2 is not a useful/balanced means because of its
inappropriate security/constraints balance (enabling is always global impact) that
breaks applications that are widely used by at least one of the audiences of
Fedora (I hope I rationally summed this up -> mjw might elaborate this position)
B) Security by default, to protect average users who are not always familiar
with all parts of their operating system and the impact of what they
customize/modify while they will not have issues with this change, and if this
affects users who are more familiar with Linux etc., it might be useful to
allow them to experience that there is an issue without a perfect solution, and
allow them to make their own decision about which compromise is best for them.
It's our job to ensure the information is available in a way they can find it
rather than making decisions for them.
In any case, it is a compromise. The new proposal has sub-sections in the
details, so that readers can skip sub-sections that ain't interesting to them
(to mitigate the too-much-text-issue a little).
While the major goal is to put it on FESCo's desk, which already contains people who dived themselves more deeply into kernel.yama.ptrace_scope, I am open to any suggestion of how to improve it. That said, be aware that this proposal is intended to be comprehensible to the whole community, not just a part of it: while I would be happy to remove text, I want that information remains that makes it comprehensible to the "everybody user". I see it critical that this community remains split between two realms that evolve separately from each other without being exposed to each other and thus not learning to understand each other’s reasoning. Much potential for feedback and collaboration lost imho, and it can explain a lot of misunderstandings I read over time (being myself mostly moderator in Discourse) -> I and also people in Discourse also identified already several kernel- and other bugs through average users (when they feel involved, they often go beyond their own problems)
or help in testing something when they have rare hardware/software constellations). Just a perspective of course.
Further, it has to be clear that I don't consider myself a software engineer: I
don't follow the exact way _how_ we make the kernel doing its job, or when/how
we exploit its means in what way, in comparison to Arch Linux or OpenSuSE etc.,
where differences are, nor do I necessarily understand intuitively the
reasoning why some things are done differently, as I lack the related
experience as engineer. In short, I know what /proc is and exploit means it
gives me as a user, but I hardly can consider the implications for an engineer
who has to consider its impact/behavior in many more (in)direct (automated)
contexts. This means also, e.g., if Fedora uses other means to achieve the same
outcome as OpenSuSE or Arch Linux, I would not necessarily know. I exploit
kernel and user space, but I'm not usually one of those who make them :) That's
why I'm happy to present the proposal for further evaluation when I'm asked by
a developer/engineer.
ptrace_scope could mitigate several attack vectors I have seen over time (from
vulnerable/obsoleted/untrusted (3rd-party) packages to processes that become
attack vectors through inappropriate user actions). That we market Fedora to
average users through our strategy might be not of major relevance for this
discussion, but it might be considered in the decisions we implement. Hope that
makes my reasoning a little clearer :)
However, keep in mind that as long as I am the sole proposal owner, I can only submit what I
can verify & "say for sure", while adding other perspectives/emphasis in the
feedback section is of course no problem.
Related Discourse discussion related to this thread:
https://discussion.fedoraproject.org/t/new-proposal-about-kernel-yama-ptrace-scope-two-perspectives-on-this-case-im-open-to-suggestions/172815
Best,
Chris/py0xc3
--
_______________________________________________
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
