> I think you're describing how to lock down an appliance. I'm talking about a development workstation. No, any production system, even a dev workstation would

> I think you're describing how to lock down an appliance. I'm talking about a development workstation. No, any production system, even a dev workstation would have IDEs and browsers restricted but their new code or anything else theh need would be permitted. I suppose the entire non-LSMed Linux/Unix acl system is broken by modern standards. (Windows as well in many similar regards), a process being able to rwx its own memory makes sense. A separate process being able to rwx any process memory so long as the target process is owned by the same user violates principles of mandator access control because it isn't mandatory for arbitrary processes with no explicitly defined relationship to alter each others' memory. In essence if I could summarize this, the permissions model is not granular enough to apply on a per-process runtime basis. You can alter the memory anyways so who cares about preloading and ptrace? That has been the thinking all along but this thinking had not adapted to modern threats and mitigations. I suppose an LSM is the only option and I wouldn't suggest fixing the root cause here due to political impracticality but it would be nice if any desktop and server distro enforced MAC adequately and at least per-process and this shouldn't be considered locked down just normal. Modifying a file, usage of the glibc feature LD_PRELOAD, ptrace,etc... while write and executing while writing and executing a file somewhere in vfs can eventually allow that, these are distinct things,it shouldn't be left for the admin to figure out the implications, the implications should be explicit by design in an ideal world. If there is no explicit permission to specifically allow an operation that constitutes a security risk the OS should prevent that operation. You only described how badly broken things are. > No! Why? There is no reason for this. It's not a security feature and it cannot serve a useful purpose. Anything you might do with LD_ vars and top you could do equally well by just copying and editing top. Yes but then the attacker would have to tamper with top (if some other security measure permits it) or use a kernel mode rootkit instead. Security controls address specific risks, in this case LD_PRELOAD is frequently abused by even the most trivial coinmining malware so that specific risk would be addressed as should any other risks in the best way possible. There is no way outside of an LSM for a developer to say "please don't permit preloading,ptrace, memory tampering unless it is this explicitly defined process because bad guys like to abuse these features against me, unless the user is explicitly warned about the dangers and permits the feature" In reality you can and people do this with selinux and the like wich are fairly cumbersome to manage by an admin (not end user). But allowing devs to declare specific risky features else defaulting to a deny would not be burdensome on devs, admins and it would make the effective security model and interface user friendly. The same thing can be said with windows process access, debug, thread/dll/code injection,etc.... these security models are outdated and user unfriendly. "If you get pwned, all bets are off" is not a good way to look st security these days.