Today and yesterday I made posts on Ask Fedora on one potentially serious security issue and one potentially important security aid that is no enabled, both on F37.
Today I noticed that not only had I not received a reply on the first one, but neither yesterdays nor today’s posts were listed in the “New” category. since Ask is moving, I’m guessing that Ask is having some problems.
This is a Discourse quirk of terminology, not a site-specific problem or anything special to your questions. “New” means something like “new posts in areas you are watching or tracking”, not “New posts on the site”. For that, you should look at “Latest”.
Is your goal here to draw more attention to these questions, or something else?
I think these are probably both better topics for here than Ask Fedora, since they are about distro security choices and potential improvements rather than really end-user support questions.
In any case, could you please give the one titled “Security issue” a more specific title?
I changed the title on the one is Ask, but that isn’t reflected in the link here. My purpose is several fold:
Draw attention to the situation.
I’m hoping that in the course of the discussion I will find out if setting ptrace’s scope to 3 manually will break Workstation (3 is the only immutable scope and “turns off” ptrace)
Perhaps find out that I shouldn’t be concerned because these things are handled differently in Workstation.
I think IMA and ptrace are sufficiently different that two different topics is fine.
As for where, I think:
“what might break if I change this option?” and “are there other mitigations in Fedora Workstation against a ptrace attack?” are good for Ask, while
“why is this off / should it be on?” (as well as a potential effort to build consensus to make future changes to defaults) is on topic here.
I am going to move this topic to the Site Help & Feedback category, though because at this point it is more about the meta issues around the questions than the questions themselves. [1]
Well today my test machine currently running Rawhide F38 was available so I tried setting
/proc/sys/kernel/yama/ptrace_scope
to 3 manually. Then I verified that the edit had worked with a cat of ptrace_scope. the ptrace_scope was indeed set to 3. Then I rebooted and did a cat of
/proc/sys/kernel/yama/ptrace_scope
and it was set back to 0. Nothing seems broken with just a once over lightly look see. I’m just guessing, but my guess is the Yama did that; so my question continues: Why is that?
As I have further researched the matter I find the SELinux policy is really the control on ptrace Using Policy Manager there is a boolean that can total deny ptrace to run but that negatively impacts ability to trace bugs and trouble shoot.
There seems to be other restriction in SELinux preventing just any running process from running ptrace. Now unless I’ve missed something I’m feeling more assured about Workstations security.