2 week man <| sep |> Things were crazy around the election . Ask again , it ' s easier now . <| sep |> Well , in this case I stand corrected . And that is indeed horrible for security . Seems like this is a thing that should be fixed , no ? No , it ' s there by design . If a debugger can ' t inspect the memory of the program it ' s trying to debug you don ' t have much of a debugger left . If an anticheat scanner can ' t do that with other programs how could it scan for cheats ? How can a virus scanner work without this ? That ' s how the Unix user account has worked and has always worked , anything that runs under your user account is free to mess with anything else , you cannot mess with other users , and you sure as hell can ' t mess with root . But as far as your other processes go it ' s fair game , and for good reason . I would hate to develop software in the world where there is no debugger . I use strace to find problems and bugs in stuff or even trying to find out just where the hell a config file is located every two days . So let ' s say that we propose to not make any random application able to access the memory of others . Now someone will say Oh , but it ' s pointless , because X allows access anyway . Yes , or in reverse . Like I said , that Wayland blocks it does little because Linux itself allows the program direct access to the memory of the compositor anyway as it doesn ' t run as root . Seems to me that either both need to be fixed at the same time , or you just have to fix one thing at a time , even if it does not lead to a perfect system . If you think the price of a locked down toy operating system unfit for serious use is worth what is essentially little more than being protected against your own foolishness of running random untrusted executables with your full user privileges . edit It seems that in fact it is not possible to access just any memory like that . Sensible systems have indeed hardened the kernel to disallow accessing the memory of other applications . See e . g . Yes , I know you can disable ptrace , but as I said , it ruins a great number of functionalities . The YAMA security module can set ptrace to four values 1 . Any process can ptrace any other process that belongs to the same user , root can ptrace all , this is what POSIX mandates and the historical behaviour . 2 . Any process can only ptrace direct descendant processes of the same user , root can still ptrace all 3 . Only root can ptrace 4 . Not even root can ptrace . If you select this setting a reboot is required to undo it since root changes these settings . You can set it to 2 or 3 or 4 , but it breaks so much . And ptrace isn ' t the only way to get into the compositor . LDPRELOAD still exists , you can just well , load a compromised binary as compositor by manipulating the PATH that just gives it out . You can indeed disable all of that and ensure all of those attacks don ' t work anymore , but each attack you disable turns your OS more and more into a locked down garden and it ' ll be less and less fit for serious use . There ' s a reason people don ' t really do anything serious on Android which has done all those things .