3 ms·

> Root-and-drop was a nuance I considered mentioning. There's a lot of incompetent code though. And there are many incompetent sysadmins out there. ;) Any syst

> Root-and-drop was a nuance I considered mentioning. There's a lot of incompetent code though. And there are many incompetent sysadmins out there. ;) Any system that has admin-configurable rules is bound to be misconfigured by some portion of its userbase. Not that SELinux's or GRSecurity's MAC systems are easy to configure, but I think that they do a better job of what you're trying to do here than either of us would be likely to do with our first couple of iterations. > The user-specificity of ports I'm speaking of would require that all access to a port be through a specified UID. Right. That's obvious. I hope you didn't think that I thought otherwise. > Nothing about keeping an otherwise, say, unused SMTP port 25 from getting snaked, no? Nothing except the fact that -on almost every Linux system, and OS X system, and modern Windows system- 25 is in the privileged range, which requires that someone with root privs run the code that binds to the port. [0] :) Generally, if you have root, you get to do whatever you want. So, if an untrusted user is running code as root, they're likely going to be able to either * reconfigure whatever system either you or I cook up to prevent them from binding their code to a particular port or * run their malicious code with whatever EUID is require to bind to the port that they want [0] Or for the system admin to have marked the binary with the right cap bits to override the privileged port restriction.

dredmorbius 11y ago
Just noting, yes, we're pretty close to understandings here. SELinux is a marvelous pain in the ass, though, isn't it? Haven't messed with GRSecurity. Also, clarifying, services which aren't running as root cannot be compromised at root level directliy from the outside. Which I hear happens.
- simoncion 11y ago
  > ...services which aren't running as root cannot be compromised at root level [remotely, barring sploit-an-error-on-the-local-machine-to-gain-root-sploits]. This is so obvious that I seriously don't understand why you're bringing it up. > SELinux is a marvelous pain in the ass, though, isn't it? Flexible MAC systems are necessarily complex. The configuration for a complex system is bound to also be complex. This is rather unavoidable.
  - dredmorbius 11y ago
    One thing age and experience have taught me is how often stating the bleeding obvious is in fact necessary. If the point is obvious to you, simply noting it is sufficient. And, yes, mapping of complex realities onto interfaces for mediating those realities typically results in complex interfaces. Those which aren't sufficiently complex have simply squeezed the actual complexity elsewhere.

dredmorbius 11y ago

Just noting, yes, we're pretty close to understandings here. SELinux is a marvelous pain in the ass, though, isn't it? Haven't messed with GRSecurity. Also, clarifying, services which aren't running as root cannot be compromised at root level directliy from the outside. Which I hear happens.

simoncion 11y ago
> ...services which aren't running as root cannot be compromised at root level [remotely, barring sploit-an-error-on-the-local-machine-to-gain-root-sploits]. This is so obvious that I seriously don't understand why you're bringing it up. > SELinux is a marvelous pain in the ass, though, isn't it? Flexible MAC systems are necessarily complex. The configuration for a complex system is bound to also be complex. This is rather unavoidable.
- dredmorbius 11y ago
  One thing age and experience have taught me is how often stating the bleeding obvious is in fact necessary. If the point is obvious to you, simply noting it is sufficient. And, yes, mapping of complex realities onto interfaces for mediating those realities typically results in complex interfaces. Those which aren't sufficiently complex have simply squeezed the actual complexity elsewhere.