What Franck was referring to is that the http server doesn't need to be root to perform its basic function(serving web pages), but it does need to be root to bind to tcp/80.
– Kevin MJul 9 '09 at 18:05

Is there a way to simply set permissions on who is allowed to bind to what port? I'd love to have a file that simply says that port 80 is owned by the apache user. This is the sort of area where plan9 has unix beat all around the block...
– chrisAug 23 '09 at 17:04

Several of the core system services provide remote interfaces to client components through Remote Procedure Calls (RPC). They are mostly exposed through named pipe endpoints accessible through the Common Internet File System (CIFS) protocol, well known TCP/UDP ports and in certain cases ephemeral TCP/UDP ports. Historically, there have been many vulnerabilities in services that can be exploited by anonymous users. When exploited, these vulnerabilities afford the attacker the same privileges that the service had on the host.

These days, protocols like BitTorrent and Skype have moved over through ephemeral ports into the unreserved space and do not bother for root access. The target is not just bypassing this old reserved-port security; Today's protocols want to bypass even the network perimeter (Skype is a good example for that). Things will go further as network bandwidth and availability increase when every computer user will probably run a web server off themselves -- and maybe, unknowingly, be part of abotnet.

We need the security desired by these old methods
but it will need to be done with newer ways now.

Well, the original thinking as I recall from the days of BSD Unix was that ports < 1024 were expected to be reserved for "well known services", and the assumption was still that servers would be relatively rare, and that folks with root privileges would be presumed to be "trusted" in some way. So you had to be privileged to bind a socket to listen on a port that would represent a network service that other users would access.

Ports 1024-4999 were intended to be used as "ephemeral" ports that would represent the client's side of a TCP connection. Ports 5000+ were intended for non-root servers.

Obviously all of those assumptions went out the window pretty quickly. Check the IANA TCP port number reservation list to see just how high things have gotten.

One solution to this problem was the RPC portmapper idea. Instead of reserving a TCP port for each service, the service would start up on a random port and tell the portmapper daemon where it was listening. Clients would ask portmapper "where is service X" listening and proceed from there. I can't recall what security mechanisms were in place to protect well-known RPC services from impersonation.

I'm not sure there's a Good Reason these days for all of this, but like most of the *nix world things tend to accumulate vs. getting completely reinvented.

Anyone read Vernor Vinge? I remember him writing in one of his novels about a computer system in the far future that incorporated layers and layers of code from the ancient past, with the time still being represented by the number of seconds since some ancient date (1/1/1970 to be exact). He's probably not far off.

Actually, which ports are ephemeral ports is implementation-specific. 1025-5000 (not 1024-4999) is Windows-specific. The IANA recommends 49152 to 65535, but only BSD listened to them.
– romandasJul 9 '09 at 18:44

A long time ago, the number of systems was much smaller. There was also no DNS, FTP sites asked for your anonymous password to be your email address, and there was no spam.

It was essentially an implied "gentlemen's agreement". Systems were well administered, if someone messed this up, you knew who to talk to, or if they were petulant, getting kicked off the network pretty much meant staying offline.

Today, with TCP/IP on everything, this is provides no security anymore.

It makes sense for services which accept system-passwords to be running on privileged ports; this means that users with shell accounts cannot set up "fake" services on the same port to capture peoples' login details, or deny access by setting up nonfunctional services on the same ports.

If you had a multiuser box, and an unprivileged user was able to set up a rogue ssh daemon, they may be able to capture the passwords of other users and gain access to their accounts (of course they'd have to do it while the legitimate ssh daemon was down, perhaps for maintenance or during system startup or shutdown)

Things which don't accept system-passwords don't matter so much, although there are major security problems with sharing things such as web servers between users on a multiuser box (as shared-hosting providers have discovered)