I was asked to put this to the discussion again before submitting the proposal. I think the current emphasis of the discussion is best discussed in the devel mailing list, but I made it a habit to always allow the whole community to add their thoughts.
Massively simplified: enabling ptrace_scope brings us to the kernel default and it mitigates some types of attacks in some contexts, which can be realistic for some audiences of Fedora, but it breaks some (mostly debugger) functions used by some software developers.
Developers can easily mitigate the issue (one command to disable it temporarily or permanently), but this can still be demotivating for those who just started working with such tools (decreasing the chance that they become active development contributors on Fedora) and all types of developers who are not yet active in the devel mailing list or reading through change proposals need to find out about how to mitigate before they can use the simple commands obviously (the proposal contains means to mitigate this issue though).
It is unlikely that “average users” will experience an impact, which is suggested by openSuSE, Arch and Ubuntu that all use the kernel default for about 10 years.
More details in my post in the devel mailing discussion:
(I’m saving space by not copying/pasting it here.)
… or in the change proposal in its current state:
However, in Discourse it might be useful to discuss if I shall change the name of the proposal: I somehow felt it useful to contain a hint in the title that tells average users what this is about (incl. the goal, which might be easier for users to link to their own case than technical implementations, and therefore allow them to give feedback about if that is important for them or not). But I am not sure if the title as it is at the moment is a bit “suggestive” and triggers average users already to vote in a certain direction. … open to thoughts
I have a simple rule of thumb: if a title is so long that it doesn’t fit on a single line, then it’s too long. This one has … four lines. That’s not a title, that’s half an essay
May I suggest “Change kernel.yama.ptrace_scope to match kernel defaults” or something along those lines?
In order to also solve the issue of being comprehensible but not suggestive to average users, what about:
Change kernel.yama.ptrace_scope to match kernel defaults (mitigates some attack vectors)
However, 2 is not a kernel default, but it is a possibility that is part of the proposal if FESCo considers this to be useful: so I’m not sure if I really shall emphasize only the 1 (kernel default) in the title and leave it to reading the details to find out that FESCo might consider 2 through the proposal? I don’t want to get feedback later that I mislead in the title (the other question is, if it is even realistic that FESCo would consider 2? If it can be already foreseen that 2 is rejected, I can save text by removing 2)
It feels like hiding the actual agency the proposal will cause, given that the documentation etc. and the possibility for 2 is part of the proposal and therefore might influence the agency of what is created and what/how is impacted. But I simplify it to a few sentences later & post here a suggestion.
I wrote this off my mind, but it might be more useful than the current one:
The package elfutils-default-yama-scope will be removed to system-wide set kernel.yama.ptrace_scope to the kernel default 1, enabling this means to mitigate some attack vectors that can rise through vulnerable/untrusted/unupdated software/packages or user actions. At FESCo’s discretion, the restrictions can be increased beyond the kernel default to 2 through adding the file 10-harden-yama-ptrace.conf (containing kernel.yama.ptrace_scope = 2) to [Making sure you're not a bot! systemd] and enable it by default in systemd.spec. Appropriate documentation for software developers affected by this change will be provided at the places they are likely to look for it, containing information how to mitigate impacts in their case (one command in each case).
… or shall I just remove the last sentence and therefore remove the part of the documentation from the summary at all ? Feels inappropriate to me, but it might save space.
I would drop this entirely. This is your proposal, so you need to know what you’re proposing - ptrace_scope = 1 or = 2. Choose one. Also, I don’t think “at FESCo’s discretion” is appropriate here, since the Change proposal is discussed with the community, and then FESCo votes on the proposal, taking community input into account, and I don’t think we should make substantive changes to proposals after it has been discussed.
Yes, I would drop this too. This is (more or less) a noop - it’s kind of expected that appropriate documentation is provided for system-wide changes like this.
I have updated the proposal (I will change the wiki URL as well according to the new title before submitting, but I leave the page for now to avoid confusion):
I only enable ptrace_scope with 1, and I add the conf file for installing/enabling 2 to systemd, along with an entry in systemd.spec, in order to raise awareness, simplify the process to enable 2 manually, and allow simpler Docs pages about 2, but I do NOT install/enable 2 by default.
new title:
Change kernel.yama.ptrace_scope to match kernel defaults (mitigates some attack vectors)
new summary:
The package elfutils-default-yama-scope will be removed to system-wide set kernel.yama.ptrace_scope to the kernel default 1, enabling this means to mitigate some attack vectors that can rise through vulnerable/untrusted/unupdated software/packages or user actions. 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 systemd and added to systemd.spec (line Source27: 10-harden-yama-ptrace.conf), but NOT enabled/installed by default.
Later parts about 2 have been either completely removed or changed to much shorter points about the file and its spec-entry that are not installed/enabled by default, in all cases being much shorter than the preceding paragraphs about it
