4 ms·

Privileged ports can be grabbed by a designated service and then handed off to an application. The application itself does not have to start as root. I believ

Privileged ports can be grabbed by a designated service and then handed off to an application. The application itself does not have to start as root. I believe systemd does this. The point is to prevent a literal nobody user on the system from grabbing 22 and MITM SSH or some similar shenanigans.

ReaLNero 4y ago
If some person has the ability to control ports and execute code, you are one kernel vulnerability away from complete disaster.
- School-Cotton 4y ago
  Yes, but that’s not a good argument for removing layers of defense.
  - _ph_ 4y ago
    It is a good argument against keeping bad layers of defense, if it is trivial to make better ones.
    - sph 4y ago
      It's not a bad layer, it's quite effective. If you do not have root, there is no way to access 1-1024 period.
      - _ph_ 4y ago
        It is not effective, if this is not the type of "attack" you have to defend against vs. plugging a Raspberry Pi with some nefarious software into the same network. But yes, I think preventing random users from opening ports listening to the world is a good idea, I don't think it should be done this way. First of all, it possibly should affect all ports and there should be a configuration file which regulates which user can open which port. Tying that privilege to the root id is the worst possible way, as discussed. The right way is to define a mapping, which userid may open a port below 1024 or at all. That would also ban e.g. a malware to operate a backdoor server on a non-privileged port. And would mean that no service requires to have root rights. These things you could do to improve, not weaken the initial concept.
- worthless-trash 4y ago
  From my limited experience, most hackers dont care for kernel, once they have your services, they have the data.. thats enough.
  - philsnow 4y ago
    attackers also want persistence and lateral movement, and privileged/kernel access makes that way easier

ReaLNero 4y ago

If some person has the ability to control ports and execute code, you are one kernel vulnerability away from complete disaster.

School-Cotton 4y ago
Yes, but that’s not a good argument for removing layers of defense.
- _ph_ 4y ago
  It is a good argument against keeping bad layers of defense, if it is trivial to make better ones.
  - sph 4y ago
    It's not a bad layer, it's quite effective. If you do not have root, there is no way to access 1-1024 period.
    - _ph_ 4y ago
      It is not effective, if this is not the type of "attack" you have to defend against vs. plugging a Raspberry Pi with some nefarious software into the same network. But yes, I think preventing random users from opening ports listening to the world is a good idea, I don't think it should be done this way. First of all, it possibly should affect all ports and there should be a configuration file which regulates which user can open which port. Tying that privilege to the root id is the worst possible way, as discussed. The right way is to define a mapping, which userid may open a port below 1024 or at all. That would also ban e.g. a malware to operate a backdoor server on a non-privileged port. And would mean that no service requires to have root rights. These things you could do to improve, not weaken the initial concept.
worthless-trash 4y ago
From my limited experience, most hackers dont care for kernel, once they have your services, they have the data.. thats enough.
- philsnow 4y ago
  attackers also want persistence and lateral movement, and privileged/kernel access makes that way easier