Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

DISCLAIMER: I know how to run daemons that either listen on ports <1024 by using privbind or some iptables REDIRECT. Or more generally spoken, how to make daemons available on priviliged ports that usually don't run there.

The question itself is kind of a meta question.

QUESTION: Why on earth is it that ports <1024 are generally reserved to the root user. From a pragmatic point of view I'd love to be able to just tell a daemon under which port to lisen on and not have to care about root privileges. The more I think about it the more I come to the conclusion that specifically this kind of "security" is just historical bloat.

A sysctl along the lines of sysctl -w net.ipv[46].conf.port.80=www-data (something like that, I hope the idea is what comes trhough) would be what I'd really desire.

This way it would be possible to maintain the "current level of security" but still allow arbitrary users to listen on lower ports. Linux capabilities (CAP_NET_BIND_SERVICE) are a first step in the right direction - at least in my mind - but given that I'm used to ports <1024 being something special I hesitate dropping the restriction completely. I just can't see an objective reason why that is the case.

Someone please enlighten me :)

Note: Yes I read some of the similiar titles but I'm not quite satisfied with a "You shouldn't be doing it". Having to jump through hoops to get apache listen on port 80 where all it does is starting up with root and then dropping privileges is unnecessary (at least I think that). Why can't I just let it run as a normal user and do it's work. That way a privilege escalation bug wouldn't even allow for root privileges. All there is are privileges of www-data (or whatever the user on the distro of choice is)

share|improve this question

1 Answer 1

up vote 1 down vote accepted

As far as I know this is, indeed, mainly just an historical convention; the idea being that when accessing a port under 1024 you can be sure you're accessing whatever the administrator of the server configured to run on the server. This made more sense back when servers where few and huge and you needed an easy way to authenticate, or at least judge the reliability of a service, by such basic means.

By the way, you may find that Capabilities do what you want. See this SO question for more information on the alternatives, but here's the sample use:

setcap 'cap_net_bind_service=+ep' /path/to/program
share|improve this answer
    
setcap works if you have kernel 2.6.24+ running –  Mike Jun 5 '11 at 1:54
    
I already new about Capabilities thanks. I'd rather like to know what will break (and why) - nfs is a good example but the clients can't possibly know wether my daemon is listening as root or not so it's basically a trust problem (in social terms) not a technical problem. The one thing I could imagine is that anybody can listen anywhere and thus just listen on all ports. Rendering the machine useless for serving "network stuff" –  Server Horror Jun 5 '11 at 12:18
    
Binding the network port may be only one of the things apache does before dropping it's privileges and you might take a look into manual or code to see. Although removing eg. apache's need to start as root sounds like a good goal , please don't misunderstand and think this will prevent priv escalatation attacks from getting to root. After all that is their purpose in life :) –  adric Jun 5 '11 at 12:33
    
It has been twelve years since RFC 2623, and ten years since Olaf Kirch wrote what you hyperlinked to. Nowadays, the world is different. The MacOS 10 NFS client defaults to using port numbers over 1024 and Linux has had the noresvport mount option since 2009. Repeating the received wisdom of over a decade ago, and saying that it's too hard to change, rather misses the fact that during the intervening decade it has changed. –  JdeBP Jun 6 '11 at 9:35
    
I missed the fact because I didn't know that, @JdeBP - why don't you post another, better answer? This is what this site is about, right? –  Eduardo Ivanec Jun 6 '11 at 10:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.