4 ms·

"It is no longer a catastrophe if an unprivileged process binds to transport layer ports less than 1024. Everyone should consider reading and writing the networ

"It is no longer a catastrophe if an unprivileged process binds to transport layer ports less than 1024. Everyone should consider reading and writing the network medium as unlimited due to hardware no longer costing a million dollars, regardless of what an operating system does." This isn't why unprivileged users are unable to bind to ports lower than 1024. Software binding to those ports is assumed to be trusted system software. Preventing unprivved users from binding to those ports prevents a malicious unprivved user from finding a way to crash one of these trusted daemons and standing up his own, malicious copy in its place.

dredmorbius 11y ago
You could accomplish the same "don't allow Joe Random UserID to bind to port X" by specifically mapping designated UIDs to ports. This doesn't require that accounts be root, avoids the security issues of running network services as root, and prevents arbitrary processes from binding to ports.
- simoncion 11y ago
  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

You could accomplish the same "don't allow Joe Random UserID to bind to port X" by specifically mapping designated UIDs to ports. This doesn't require that accounts be root, avoids the security issues of running network services as root, and prevents arbitrary processes from binding to ports.

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