Mitigation:
sudo sh -c "printf 'kernel.yama.ptrace_scope=2' > /etc/sysctl.d/10-ptrace.conf"
and reboot
The mitigation comes from the original blog, but the code to implement it is not there. It’s my adaptation from mitigations in previous exploits.
Some more info - https://www.kernel.org/doc/Documentation/security/Yama.txt
I wonder if we really need to raise to 2, since the default on manjaro seems to be 1, which is already somewhat restricted. But since i do not have a full understanding of the kernel and i do not use debuggers i would raise it first until someone more knowledgable explains.
I just re-enabled the systemd service I created for the previous ptrace_scope vulnerability (although I did change the /usr/bin/ file setting from 3 to 2):
Confirmation it is working:
❯ sysctl kernel.yama.ptrace_scope
kernel.yama.ptrace_scope = 2
Isn’t it a bit convoluted? Sure it works, making a service to execute a script that changes setting at runtime…but you can just make a dropin config and it will work on boot. Sysctl and its config are made for this. It’s just simpler. I remember changing swappiness this way before systemd and its services even existed.
Probably, and at the time I wrote it I didn’t think of the /etc/sysctl.d/ drop-in option.
Also, I thought it easier (for myself anyway) to have a service that I could disable/enable at anytime via systemctl, especially as I am usually running a RC kernel, and occasionally switching between kernels which may or may not be patched at the time.
How we gonna remove that Mitigation, when it comes obsolete?
Delete the file /etc/sysctl.d/10-ptrace.conf
You’ve been around long enough to understand that command.
sudo sh -c "..." # run a command in a root shell
printf 'kernel.yama.ptrace_scope=2' # print "kernal.yama.ptrace_scope=2"
> /etc/sysctl.d/10-ptrace.conf # redirect to a file, this is why sudo sh -c is needed
# though echo ... | sudo tee ... would also work
Files in /etc/sysctl.d are processed during boot.
So you
and reboot.
I ran into an application issue after applying this mitigation, it’s in relation to a Wine/Proton compat lay Windows application that has DotNot(9) as dependency.
After adding the mitigation and reboot the application would no longer start. Journal log showing ptrace related entries.
The application in question is Vortex Mod Manager, setup through Lutris, configured to use Proton10 as compat layer.
Anyone have thoughts on the why of this?
This is unfortunately possible with some windows apps/games. You can read about ptrace to understand what it does if you can (me - i could only to an extent). Simply said some winboze apps try to squeeze performance or prevent cheating, or are badly coded so they want to influence other processes, which is generally not their job and potentially dangerous.
That is the very simplified version. Raising this protection isolated processes even more and thus when they cannot reach out they crash.
Removing the .conf file returns the default value of 1 which a little bit more lax. Values 0 (no protection) and 3 (extreme) are NOT recommended. Don’t do anything else that 1 or 2.
Pretty much every app that is not a windows game or virus should be ok with 2.
If you see other games/apps that are not happy with 2, please leave a comment.