Today I noticed that yama is stuck in the “becoming mindful” state (hasn’t done anything). Also the ptrace scope is set to 0:
cat /proc/sys/kernel/yama/ptrace_scope
returns 0, which indicates “classic” run mode which is vulnerable to attack.
I haven’t done anything to cause this; so I assume this is the default as installed state for Fedora Worksstation Linux.
This seems to be a potentially dangerous situation. Why is this so?
Thanks in advance for your help on this.
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?
To make changes to kernel sysctls persist across reboots, you need to put them a file (with any name) in /etc/sysctl.d. In this case, that file should have a line like this:
kernel.yama.ptrace_scope = 3
All security decisions trade increased protection against some threat for reduced functionality or performance or convenience.
When a new security feature is developed, or a new threat becomes of concern, someone needs to analyze the trade-off and make a decision.
Sometimes, the answer to questions like these is simply that no one has done the analysis. Or, sometimes, at a quick glance, the threat doesn’t seem to be worth the cost, and nothing goes further.
I’m not sure if that’s the case here, but there are a lot of useful reasons to trace a process, and as I understand it, it’s vital to Wine (and therefore all of those Steam games). At the same time cross-process tracing is a relatively narrow threat.
We do have another way to block cross-process tracing — see Features/SELinuxDenyPtrace - Fedora Project Wiki. But, that’s not on by default either.
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.