3 ms·

Sure, from a security perspective, there's no requirement that 0 be the only UID that can bind to privileged ports. But by doing what you suggest, you've create

Sure, from a security perspective, there's no requirement that 0 be the only UID that can bind to privileged ports. But by doing what you suggest, you've created a privileged user that can create privileged processes. The author states: "It is no longer a catastrophe if an unprivileged process binds to transport layer ports less than 1024." except that -from a security perspective- it kind of is. :) Edit: To put a finer point on this and make it more explicit: Permitting unprivileged users to bind to "privileged" ports changes a service crash bug from a DoS into a complete service takeover.

dredmorbius 11y ago
If one and only one UID can bind to a given port (much the way other service access is limited by UID or GID), then you're reducing overall attack surface: 1. You're eliminating entire classes of root-level processes. 2. You're restricting all other non-root processes from accessing those port(s).
- simoncion 11y ago
  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.

dredmorbius 11y ago

If one and only one UID can bind to a given port (much the way other service access is limited by UID or GID), then you're reducing overall attack surface: 1. You're eliminating entire classes of root-level processes. 2. You're restricting all other non-root processes from accessing those port(s).

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