3 ms·

I mostly agree. I guess you misunderstood what I wrote. I was double-checking to ensure that you understood that my original comment was addressing only the au

I mostly agree. I guess you misunderstood what I wrote. I was double-checking to ensure that you understood that my original comment was addressing only the author's assertion, [0] and that I did not intend to assert that the only way to achieve the same security properties of the current way of doing things was the way things were currently done. :) > 1. You're eliminating entire classes of root-level processes. Eh... Given that the way this sort of thing is currently handled is to bind as root, then drop privs and fork, handing the FD to the bound socket to the forked child, nothing competently written ends up running as root that doesn't need to run as root for other reasons. (For example: sshd needs to switch to any user on the system, so it runs as root. Apache only needs to access things that httpd can access, so it runs as httpd.) Edit: > 2. You're restricting all other non-root processes from accessing those port(s). Linux already does this, but in a more general way. If you don't pass SO_REUSEPORT, you can't bind to a port that's already in use. If you do use SO_REUSEPORT, only code with the same EUID as the first code to bind to that port can bind to that port. See [1] for details. Edit 2: This might also interest you: http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-1024-on-l/414258#414258 http://stackoverflow.com/questions/413807/is-there-a-way-for... [0] Which was: "It is no longer a catastrophe if an unprivileged process binds to transport layer ports less than 1024." (Emphasis mine.) [1] https://lwn.net/Articles/542629/ https://lwn.net/Articles/542629/

dredmorbius 11y ago
Root-and-drop was a nuance I considered mentioning. There's a lot of incompetent code though. I may have written some of it. The user-specificity of ports I'm speaking of would require that all access to a port be through a specified UID. Port reuse would only prevent attaching to already active ports. Nothing about keeping an otherwise, say, unused SMTP port 25 from getting snaked, no?
- simoncion 11y ago
  > 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

Root-and-drop was a nuance I considered mentioning. There's a lot of incompetent code though. I may have written some of it. The user-specificity of ports I'm speaking of would require that all access to a port be through a specified UID. Port reuse would only prevent attaching to already active ports. Nothing about keeping an otherwise, say, unused SMTP port 25 from getting snaked, no?

simoncion 11y ago
> 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.