4 ms·

stopping non root users from listening on low ports probably causes more security issues than it solves, it means crappy admins and developers just gift root ac

stopping non root users from listening on low ports probably causes more security issues than it solves, it means crappy admins and developers just gift root access to exploits.

ratsmack 11y ago
But that isn't a problem with the software, it's just human laziness. I don't know of any system that prevents a person from making poor choices.
- andrewchambers 11y ago
  I just gave you an example, if you don't force them to be root to do something, they wouldn't have bothered, preventing the poor choice.
simoncion 11y ago
> ...crappy admins and developers just gift root access to exploits. Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root. > ...stopping non root users from listening on low ports probably causes more security issues than it solves... Requiring root privs to bind to low ports prevents the following attack: * Attacker knows of a way to crash $SERVICE * Attacker has a non-root shell on $MACHINE, which runs an instance of $SERVICE * Attacker crashes $SERVICE and stands up his own malicious instance The ability to prevent an attacker from turning a service crash bug + an unprivved shell into a malicious instance of that service is a good property to have. The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port. I'm not willing to give up that property in order to make an incompetent sysadmin or developer slightly less likely to run an exploit as root.
- andrewchambers 11y ago
  > Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root. I don't think you have a firm grasp of the state of the real world.
  - simoncion 11y ago
    > I don't think you have a firm grasp of the state of the real world. I expected you to make this objection. :) I have a rather firm grasp of the current state of both development and system administration. Note carefully that I said "$CLASS shouldn't $DO_IMPORTANT_THING", rather than "$CLASS doesn't $DO_IMPORTANT_THING". It's a subtle detail that I guess you missed. ;) I also notice that you didn't address my larger, more technical point. I guess that means that you didn't find fault in it. That's good, as it's pretty universally recognized that it's a good thing when you get near-zero-cost removal of a given class of exploits.
- useerup 11y ago
  > The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port. Ahem. That's what Windows does. The built-in firewall (on by default on all versions) will block all attempts to receive, unless a rule specifically allows it. A rule can specify that a specific account (or group) can receive on a specific port. However, it is more common to have rules authorize programs to communicate, like e.g. allowing chrome to open outgoing TCP connections, or allowing a specific service to listen on specific ports.
  - simoncion 11y ago
    > Ahem. That's what Windows does. No need to clear your throat, I'm aware of Windows Firewall. :) I've never had to do real administration of a Windows system, so I ask: Does WF allow you to restrict which programs can be bind to a given port? This [0] doesn't make it seem like it can, [1] and my gaming machine is booted into Linux for the next several hours, so I can't check for myself. :( [0] https://technet.microsoft.com/en-us/library/cc753558.aspx https://technet.microsoft.com/en-us/library/cc753558.aspx [1] Though -frankly- it's not the best intro to that UI that I've ever seen. :(
    - useerup 11y ago
      > Does WF allow you to restrict which programs can be bind to a given port? Yes. > This [0] doesn't make it seem like it can Indeed. Also check out the cmdlets of the PowerShell NetSecurity module: gcm -mod netsecurity Basically a rule can filter on any combination of local/remote IP/port, user/account/group, program/path, service, interface type (wireless/wired...), profile (domain/public/private/...), protocol and and more. > [1] Though -frankly- it's not the best intro to that UI that I've ever seen No, it's pretty bad. :-) Not even a screenshot.
      - mschuster91 11y ago
        Hate to say it, but out of the box Windows has the most flexible firewall compared to OS X and Linux. Neither platform can deny/allow traffic by the process full path (a Unix app can spoof its process name shown in ps/top) or in a GUI... at least one thing Windows got right.

stopping non root users from listening on low ports probably causes more security issues than it solves, it means crappy admins and developers just gift root access to exploits.

ratsmack 11y ago

But that isn't a problem with the software, it's just human laziness. I don't know of any system that prevents a person from making poor choices.

andrewchambers 11y ago
I just gave you an example, if you don't force them to be root to do something, they wouldn't have bothered, preventing the poor choice.

simoncion 11y ago

> ...crappy admins and developers just gift root access to exploits. Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root. > ...stopping non root users from listening on low ports probably causes more security issues than it solves... Requiring root privs to bind to low ports prevents the following attack: * Attacker knows of a way to crash $SERVICE * Attacker has a non-root shell on $MACHINE, which runs an instance of $SERVICE * Attacker crashes $SERVICE and stands up his own malicious instance The ability to prevent an attacker from turning a service crash bug + an unprivved shell into a malicious instance of that service is a good property to have. The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port. I'm not willing to give up that property in order to make an incompetent sysadmin or developer slightly less likely to run an exploit as root.

andrewchambers 11y ago
> Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root. I don't think you have a firm grasp of the state of the real world.
- simoncion 11y ago
  > I don't think you have a firm grasp of the state of the real world. I expected you to make this objection. :) I have a rather firm grasp of the current state of both development and system administration. Note carefully that I said "$CLASS shouldn't $DO_IMPORTANT_THING", rather than "$CLASS doesn't $DO_IMPORTANT_THING". It's a subtle detail that I guess you missed. ;) I also notice that you didn't address my larger, more technical point. I guess that means that you didn't find fault in it. That's good, as it's pretty universally recognized that it's a good thing when you get near-zero-cost removal of a given class of exploits.
useerup 11y ago
> The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port. Ahem. That's what Windows does. The built-in firewall (on by default on all versions) will block all attempts to receive, unless a rule specifically allows it. A rule can specify that a specific account (or group) can receive on a specific port. However, it is more common to have rules authorize programs to communicate, like e.g. allowing chrome to open outgoing TCP connections, or allowing a specific service to listen on specific ports.
- simoncion 11y ago
  > Ahem. That's what Windows does. No need to clear your throat, I'm aware of Windows Firewall. :) I've never had to do real administration of a Windows system, so I ask: Does WF allow you to restrict which programs can be bind to a given port? This [0] doesn't make it seem like it can, [1] and my gaming machine is booted into Linux for the next several hours, so I can't check for myself. :( [0] https://technet.microsoft.com/en-us/library/cc753558.aspx https://technet.microsoft.com/en-us/library/cc753558.aspx [1] Though -frankly- it's not the best intro to that UI that I've ever seen. :(
  - useerup 11y ago
    > Does WF allow you to restrict which programs can be bind to a given port? Yes. > This [0] doesn't make it seem like it can Indeed. Also check out the cmdlets of the PowerShell NetSecurity module: gcm -mod netsecurity Basically a rule can filter on any combination of local/remote IP/port, user/account/group, program/path, service, interface type (wireless/wired...), profile (domain/public/private/...), protocol and and more. > [1] Though -frankly- it's not the best intro to that UI that I've ever seen No, it's pretty bad. :-) Not even a screenshot.
    - mschuster91 11y ago
      Hate to say it, but out of the box Windows has the most flexible firewall compared to OS X and Linux. Neither platform can deny/allow traffic by the process full path (a Unix app can spoof its process name shown in ps/top) or in a GUI... at least one thing Windows got right.