3 ms·

> "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."

> "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." This doesn't sound like a net positive policy. > "I suppose the entire non-LSMed Linux/Unix acl system is broken by modern standards." Hey look, I've worked in infosec too. These ideas you have come with a cost. You're starting to include language, terminology and design choices that are clearly derived from a large one-size-fits-all corporate environment. I've worked with similar environments and I understand why they exist -- but they are not the norm and are certainly not representative of an ideal computing environment (in terms of security, or in general) > "You only described how badly broken things are." I described a development system where things can be changed. You're describing a calcified system where safety is imposed by controls and invariance. Those costs are worth paying for some environments but absolutely not for others. > "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." No, there are dozens of ways to supply a modified behavior in top. If you're mucking with the environment, why not just change PATH? After all, the LD_ variables are just linker paths. This is a very silly thing to fixate on. > " There is no way outside of an LSM for a developer to say "please don't permit preloading" Uh, of course there is. LD_* environment variables are just inputs to the linker. You can trivially change the linker to ignore these variables, or behave differently with them, or whatever. > "ptrace" Also really easy to limit with seccomp. This is SOP for containers - it's built into docker. It happens by default for most use cases. > "But allowing devs to declare specific risky features else defaulting to a deny" Look, here's the thing: There's always going to be a lowest hanging fruit. I know there's a fairly common compulsion in the security industry to point at the lowhanging fruit and say "that's the problem! remove it!" but this is a fallacy. It's just not true. What actually matters is whether or not the permission model is cohesive and readily understandable by a developer. Locking down syscalls is and stripping features from a containerized app is a great idea in certain contexts. It's a terrible idea in others. The ideas you're proposing aren't creating strict controls - they're just chasing misbehaviors. This makes a lot of sense for a large organization playing the numbers game, but it cannot lead to a cohesive, consistent, general purpose security architecture.

_8j50 4y ago
> This doesn't sound like a net positive policy. Sounds like? Well it is net positive regardless of how it sounds. Intuition is not a good way to direct or measure security. > Hey look, I've worked in infosec too. These ideas you have come with a cost. You're starting to include language, terminology and design choices that are clearly derived from a large one-size-fits-all corporate environment. I've worked with similar environments and I understand why they exist -- but they are not the norm and are certainly not representative of an ideal computing environment (in terms of security, or in general) > The ideas you're proposing aren't creating strict controls - they're just chasing misbehaviors. This makes a lot of sense for a large organization playing the numbers game, but it cannot lead to a cohesive, consistent, general purpose security architecture. So first of all I heavily resent that sentiment! I also had someone else last week refusing to argue from a technical standpoint and esentially say "that's corporate stuff, it's not popular" do you hear yourself? Who cares? Second, it absolutley is not a corporate thing, this is what android,macos,ios are doing, they are very much popular and modern. When an app needs access to a camera you need to give permission right? It wasn't that way at the start and they learned the hard way that allowing a process to access anything because of implied permissions lead to disaster. This is exactly what I am suggesting except I am making it holistic. This is "zero trust" but at the application level. You're stuck in the past and on what linux cliques and popular personas consider popular. I care about bad guys causing harm on any platform, I've seen these risky features getting abused by threst actors that is motivation. From a corporate perspective I don't care about hardening, I care about logs/monitoring because I can afford to log everytime ldpreload or ptrace is used and do something about it. A guy using ubuntu for gaming and web browsing doesn't get like you that installing a program/package without carefully understanding its capability, authorship and the unix permissions model, syscalls, procfs and all kinds of subsystems means he's screwed. For that guy, defaults matter and the default should align with user expectations when it comes to risky features not developer expectations. > No, there are dozens of ways to supply a modified behavior in top. If you're mucking with the environment, why not just change PATH? After all, the LD_ variables are just linker paths. This is a very silly thing to fixate on It's not silly because bad guys abuse it. If there are other means default them to deny/off. Stop offloading default security to end users/admins. > Also really easy to limit with seccomp. This is SOP for containers - it's built into docker. It happens by default for most use cases. Don't you need to write the app with seccomp support? 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? > Look, here's the thing: There's always going to be a lowest hanging fruit. I know there's a fairly common compulsion in the security industry to point at the lowhanging fruit and say "that's the problem! remove it!" but this is a fallacy. It's just not true. 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 not just these things and please making assumptions about my intentions/background. Any device in /dev, any risky file in procfs or sysfs, any abusable syscall , enironment variable, file acl, network connection default them all to a deny and allow users a friendly means by which to disable the restriction. If you don't like my suggestion that's fine so long as the current mess isn't considered acceptable. Security should be the default and risky exposures should be identified and disabled by default by the OS maintainer not the end user or admin. The corporate way would be how things are now, pay an admin and a consultant and a manager to painstakingly maintain, audit and service file acl restrictions on a fleet of servers and users which isn't ideal for lone admins, newbies and desktop users in general. > What actually matters is whether or not the permission model is cohesive and readily understandable by a developer. Locking down syscalls is and stripping features from a containerized app is a great idea in certain contexts. It's a terrible idea in others. No, what actually matters is the security model and default securitu exposures being easily understandable by a minimally experienced user or admin and easily alterable by experienced admins/devs to suit their needs and that isn' how things are today. Your comment about context is spot on, what is bad is your assumption that defaults should be insecure to suit lazy developers instead of default being secure and as needed developers loosening restrictions. > "they're just chasing misbehaviors" No, these are real security exposures, of course, if restrictions can be applied at a more fundamental level without impacting users that would also be great. For example with preloading, I get that there are different ways of using that feature so I simply patched it out of glibc in past systems. But it would have been great if there was at least a complile flag to disable it and even better if it was a runtime option disabled by default until I need it. Assumptions are dangerous to everyone. 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.

_8j50 4y ago

> This doesn't sound like a net positive policy. Sounds like? Well it is net positive regardless of how it sounds. Intuition is not a good way to direct or measure security. > Hey look, I've worked in infosec too. These ideas you have come with a cost. You're starting to include language, terminology and design choices that are clearly derived from a large one-size-fits-all corporate environment. I've worked with similar environments and I understand why they exist -- but they are not the norm and are certainly not representative of an ideal computing environment (in terms of security, or in general) > The ideas you're proposing aren't creating strict controls - they're just chasing misbehaviors. This makes a lot of sense for a large organization playing the numbers game, but it cannot lead to a cohesive, consistent, general purpose security architecture. So first of all I heavily resent that sentiment! I also had someone else last week refusing to argue from a technical standpoint and esentially say "that's corporate stuff, it's not popular" do you hear yourself? Who cares? Second, it absolutley is not a corporate thing, this is what android,macos,ios are doing, they are very much popular and modern. When an app needs access to a camera you need to give permission right? It wasn't that way at the start and they learned the hard way that allowing a process to access anything because of implied permissions lead to disaster. This is exactly what I am suggesting except I am making it holistic. This is "zero trust" but at the application level. You're stuck in the past and on what linux cliques and popular personas consider popular. I care about bad guys causing harm on any platform, I've seen these risky features getting abused by threst actors that is motivation. From a corporate perspective I don't care about hardening, I care about logs/monitoring because I can afford to log everytime ldpreload or ptrace is used and do something about it. A guy using ubuntu for gaming and web browsing doesn't get like you that installing a program/package without carefully understanding its capability, authorship and the unix permissions model, syscalls, procfs and all kinds of subsystems means he's screwed. For that guy, defaults matter and the default should align with user expectations when it comes to risky features not developer expectations. > No, there are dozens of ways to supply a modified behavior in top. If you're mucking with the environment, why not just change PATH? After all, the LD_ variables are just linker paths. This is a very silly thing to fixate on It's not silly because bad guys abuse it. If there are other means default them to deny/off. Stop offloading default security to end users/admins. > Also really easy to limit with seccomp. This is SOP for containers - it's built into docker. It happens by default for most use cases. Don't you need to write the app with seccomp support? 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? > Look, here's the thing: There's always going to be a lowest hanging fruit. I know there's a fairly common compulsion in the security industry to point at the lowhanging fruit and say "that's the problem! remove it!" but this is a fallacy. It's just not true. 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 not just these things and please making assumptions about my intentions/background. Any device in /dev, any risky file in procfs or sysfs, any abusable syscall , enironment variable, file acl, network connection default them all to a deny and allow users a friendly means by which to disable the restriction. If you don't like my suggestion that's fine so long as the current mess isn't considered acceptable. Security should be the default and risky exposures should be identified and disabled by default by the OS maintainer not the end user or admin. The corporate way would be how things are now, pay an admin and a consultant and a manager to painstakingly maintain, audit and service file acl restrictions on a fleet of servers and users which isn't ideal for lone admins, newbies and desktop users in general. > What actually matters is whether or not the permission model is cohesive and readily understandable by a developer. Locking down syscalls is and stripping features from a containerized app is a great idea in certain contexts. It's a terrible idea in others. No, what actually matters is the security model and default securitu exposures being easily understandable by a minimally experienced user or admin and easily alterable by experienced admins/devs to suit their needs and that isn' how things are today. Your comment about context is spot on, what is bad is your assumption that defaults should be insecure to suit lazy developers instead of default being secure and as needed developers loosening restrictions. > "they're just chasing misbehaviors" No, these are real security exposures, of course, if restrictions can be applied at a more fundamental level without impacting users that would also be great. For example with preloading, I get that there are different ways of using that feature so I simply patched it out of glibc in past systems. But it would have been great if there was at least a complile flag to disable it and even better if it was a runtime option disabled by default until I need it. Assumptions are dangerous to everyone. 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.