> "Well it is net positive regardless of how it sounds." You can't just state that lol. I am certain it is at a minimum unsettled as I've had many discussions

> "Well it is net positive regardless of how it sounds." You can't just state that lol. I am certain it is at a minimum unsettled as I've had many discussions with peers across the field about the relative tradeoffs. Including the dangers of superficial measures which aren't in sync with the underlying security architecture. > " this is what android,macos,ios are doing, they are very much popular and modern" It's what consumption platforms are doing. It's typically disabled on development platforms because the cost is too high. > "When an app needs access to a camera you need to give permission right?" But this isn't what you're describing and this isn't new. Unix has had permissions on devices since its inception. Using multiple per-app users is becoming more mainstream, but this sort of thing is in sync with what I'm describing above. It has nothing to do with the underlying security model as to how users interact with resources they own, or this wishy-washy concept of intra-user security -- which, again, isn't how these controls are implemented on platforms like Android. Android creates a new user for every application. Unix has been doing this since the dawn of time, giving individual users or apps permission to specific devices. What you're talking about is something entirely different: How users interact with their own objects which are already owned by them. > "Stop offloading default security to end users/admins." Default security is fine, but you are talking about intra-user controls on objects vs using the system's security architecture (as above: Android uses separate users per app instead) > "Don't you need to write the app with seccomp support? " No, you don't! This is something done in a config file when spinning up a container and it will work for arbitrary processes within the container. You can basically configure away certain syscalls and so on if you know they aren't/shouldn't be used. You can even make this part of an app architecture (aka: android app packaging) to standardize the permissions interface. When apps publish a dockerfile, this is what they're doing. > "How can a user turn that off if they want to debug it? And how would an end user know to do this or even a developer, if your default is to allow ptrace what motivates them to limit ptrace?" These features exist for packaged apps and limit access from the app's perspective. Other debug enabled processes (aka: my workstation shell) can still call ptrace and attach. It's all part of the security model. > "I don't think what I am saying is getting across. Preloading and ptrace are low hanging frequently abused things for sure and that's why I mentioned them but my suggestion is to overhaul everything " I think we might be talking past each other. It's fine to lock down developed applications to limit scope. This is the entire point of containers! What I'm talking about though is access from already privileged execution units. We don't need to protect chsh from LD_PRELOAD because if it's running setuid then it's already ignoring it, and if it isn't, there's no threat because we already control all the related objects. > "what is bad is your assumption that defaults should be insecure " My suggestions are secure, and in fact are how android, osx, etc currently operate! I have a shell on an android right now. The browser is running as a separate user in a locked down environment. The entirety of /bin/ is not and I'm allowed to play with the linker parameters in development -- but not from within a production app. I think we agree that locking down a production app is reasonable. I think where we're getting off the rails is regarding features for a developer who wants to work on their own system -- like LD_PRELOAD. I'm sure you agree that a developer workstation should support this, right? Or an android with developer mode enabled? Etc? Because it does work that way on these modern platforms. > "Lastly, this has to be the longest HN thread I've replied to. You do have solid arguments, I only wish we could have this discourse in a more suitable place. " For sure. Enjoying this discussion and thank you