Very technical post here. Among the children of Unix (Linux/BSDs/MacOS) there is a convention that for a program to open a TCP or UDP port from 0 to 1023, it must have superuser permission. The idea is that these ports are privileged, and you don't want just any random program taking control of such a port and pretending to be (or blocking out) a system service like Email or DNS or the web.

This makes sense, but the result is that all programs that provide such services have to start their lives as the all-powerful superuser, which is a security threat of its own. Many programs get superuser powers just so they can open their network port and, and then discard the powers. This is not good security design.

While capability-based-security (where the dispatcher that runs programs gives them capability handles for all the activities they need to do) would be much better, that's not an option here yet.

I propose a simple ability to "chown" ports (ie. give ownership and control like a file) to specific Unix users or groups. For example, if there is a "named" user that manages the DNS name daemon, give ownership of the DNS port (53) to that user. Then a program running as that user could open that port, and nobody else except root (superuser) could do so. You could also open some ports to any user, if you wanted.

This could be a file read by the kernel, or an actual filesystem with special nodes could be created (/dev/port/tcp/nnn) so programs could actually use the official chown call on it. (Indeed, these files could actually work as the sockets, but most programs would continue to use the standard TCP socket call, which would have to check the permissions.) Alas, a /proc fake filesystem might work as an interface, but would not have the permanence required.

Many programs could run in this environment without modification, in that they would run as an ordinary user, open the socket (thinking they are root) and then setuid to their real self (which would do nothing.) However, you would no longer be trusting them with root. Of course some programs still need root (mail agents need to write mailboxes owned by anybody in most mail systems, some web browsers like to run CGIs as the user, etc.) though many of them can be altered to not need it, or just make occasional use of an isolated suid program (as qmail does for mail.) And of course, until a kernel with this feature is widely distributed, servers would have to support both methods.

Note there is no reason you couldn't apply this system to the entire port space. In particular, while the default of allowing all higher ports to be used by any program needs to be preserved, you could grant ownership of specific high ports to specific users so that they can be sure no other program will grab their expected port to try to interfere with them. However, a wise program would be able to deal with not getting its favourite port, since we don't want to build a general port reservation system for any program that arises.