Running services without root user required to bind to ports
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Running services without root user required to bind to ports
Hi All
I don't know why more people aren't doing this or why its not documented a lot more than i believe it is, which makes me think that perhaps there's something wrong with doing things like this:-
Have a service/program that you require to be able to bind to a port with for arguments sake i'm going to say apache. Now we mostly now all start apache with the root user so it can bind to a privileged port within the 0-1024 range, probably 80 and perhaps 443 as well. However why do we do this, it seems even better and even more secure not starting apache using the root user at all, meaning root then has absolutely nothing to do with apache and if apache was comprised, that alone has no chances of escalating to root user privileges as far as i can see. This is all possible by getting apache to bind to a non-privileged port and then forwarding on any packets going to port 80 and 443 with an iptables redirect. This works just fine and the root user has nothing to do about it, why aren't we doing this with any services people want to run or bind to on a port in the 0-1024 range where as its my believe most people just run the service/program the root user instead leaving the box more open to attack? this seems so simple and yet like i say i don't really see it documented all over the place, so is there something wrong with doing things like this? If the service/program sends back replies on the port its running on then there's no reason we couldn't catch those on the way out and redirect them again to leave from the port number that people are connecting to.
Its just something that seems to me as if it could make such a security improvement from the point of view if a service/program is compromised, so often we see this running as root and then the box is shot, but with this method unless i'm way off?? this would not so be the case, the service may still get compromised however the way i see it, an attacker still then has to take the time to elevate privileges from there to get root???
I Hope that makes sense, that people find it useful, and that i can get some answers as to why its not such an obvious thing to be doing?? It seems pretty good to me??
ps - an after thought, is i guess some services make use of system libraries etc, but compiling services from source you can make a user and have it own anything it requires and as long as the libraries aren't dynamically linked which they shouldn't be when compiled from source this shouldn't be a problem??
Cheers,
Mark
Last edited by helptonewbie; 02-19-2008 at 10:49 AM.
Skipping intro about history, "trusted" ports, IANA etc etc, looking at Apache the parent thread runs as root but takes care of just a few things. Its spawns children that run as unprivileged user and *they* handle requests from the network. This isn't something novel, it's called separation of privilege. And while you'd think your idea solves problems, changing a service to run on another port from it's designated one can actually cause all sorts of problems.
cheers unspawn, although i'm yet to come across a problem with a service that can't operate like it. On the other hand i've not really tried it with any service appart from home made services/programs. But i think i'm certainly going to try out some of the main targets like ssh etc, and see what happens, the only part i can see issues being caused is possibly permissions violations in some circumstaces however if running from a compiled source this shouldn't really happen i wouldn't have thought. I know apache spawns off children and those apache threads only run as the user you specify, but i was only using apache as an example. I'm not sure ow it could cause a service to many problems as the service can run perfectly ok on whatever port you tell it (in most cases i'm thinking of for my own requirements at least), and the service itself would be un-aware of the fact that packets are being redirected to it (perhaps this being the issue??). vice versa if the service were to try and reply on the actual port its set-up on, then i can catch those packets on the way out and then redirect out the inital port. That doesn't happen so much now anyway, i'm sure you know that a connectoin will come in acks and syns and all that are delt with and most then pick a port to continue running on from the port pool rather than continuing on the service's port (certainly in sshd circumstances). Therefore that would happen as normal also?
Can you give an example that a service wouldn't like what this sugests, i'm very interested in this today and its got me thinking, but maybe i've thought way ahead and not looked at other issues first??
Thanks Unspawn
Last edited by helptonewbie; 02-19-2008 at 01:03 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.