New proposal about kernel.yama.ptrace_scope: two perspectives on this case -> I'm open to suggestions

Project Discussion
, , ,
1

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 :classic_smiley:

@mjw FYI :classic_smiley:

2

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 :laughing: :sob:

May I suggest “Change kernel.yama.ptrace_scope to match kernel defaults” or something along those lines?

1 Like
3

Similarly, the Summary is five paragraphs. The Change template says:

A sentence or two summarizing what this change is and what it will do.

2 Likes
4

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 :classic_smiley: (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)

5

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.

6

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.

7

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.

2 Likes
8

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

2 Likes
9

I was asked by a few developers to change the title again to something that describes the functional impact [1] of the change.

I disagree with the suggestion in the mailing list, as it is formally not correct and misleading to several affected users, but I agree that it would be useful to have a title that tells the reader already about what this change is doing.

I just drafted this as alternative, while it is longer again (but only a bit):

Restrict ptrace for unprivileged users by default to child processes (mitigates some attack vectors)

It’s formally also not very precise, but with regards to the comments, that seems to be not expected anyway, and I think this reflects the outcome for all targeted audiences.

I found it useful and important to have contained that this change brings us to the kernel default (as described by the previous title), because this result is also useful for us, but then the title would again get quite long…

I’ll think about it before putting it, or something comparable, to the devel mailing list tomorrow or the day after. But open to alternatives of course.

10

I already observed in the first debate (now again) that in the ptrace_scope part, people regularly introduce, somehow intuitive, assumptions about this breaking software development at all or to render all ptrace in user accounts unusable forcing users to root, and thus responding in the debate correspondingly to these assumptions.

Since I am not sure if I can tackle this every time it becomes “incorporated” again (a thunderbird bug currently makes it 5 minutes for me to answer one email), so I think this title should hint the reader at first glance that it cannot be that worse, as other developer distributions do it too, along with kernel default:

Restrict ptrace for unprivileged users to child processes by default, following ArchLinux,openSuSE,Ubuntu and kernel default (mitigates attack vectors)

Supplement, implementing all three types of feedback, I tend to stick with:

Restrict ptrace for unprivileged users to child processes to match kernel default

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 [Making sure you're not a bot! systemd] and added to systemd.spec (line Source27: 10-harden-yama-ptrace.conf), but NOT enabled/installed by default.

→ this tackles the two presumptions that seem to end up in every discussion, but shortens the title below the earlier one that seems to have been short enough for everybody, and the summary is just a few words more (given the responses in all three devel discussions, it seems a general summary + title always seem to make some people think that this cannot be undone and makes Fedora unusable for development, which is a serious misunderstanding)

11

Submitted as …

Restrict ptrace for unprivileged users to child processes to match kernel default

→ Changes/Restrict ptrace for unprivileged users to child processes to match kernel default - Fedora Project Wiki

I removed another paragraph and tried to keep it aligned among the different feedback.