Serversockets on ports <1024 without ever lasting root access

Newbie & Debugging Questions
#1

I’m fairly sure that to host serversockets under 1024 on linux, you need root access. Now that’s not really a problem, because I have the password, but I don’t really want to run that app with root-access after the moment the serversocket is bound.

Can I somehow switch the user of a running process from the commandline interface?

I googled it, but I might be searching with the wrong terms, or searching in the wrong direction.

Anybody got experience with ‘securing’ a java (web)server, to ‘drop its privileges’ ?

#2

This is for RMI, but I think it would work in your case:

http://www.davidreilly.com/java/java_network_programming/

More info here: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rsec_rpolicydir.html

#3

Nope, this has nothing to do with SecurityManagers :slight_smile:

It’s about Linux user management

#4

You can change the effective user running the process by running sudo before hand. However, this would just mean the process would be run by user “riven” but they would have superuser permissions (presumably not what you were aiming at).

(AFAIK :)) Other than that on *nix the ports under 1024 are entirely superuser access only and you can’t change the permissions on a running process unless you call setuid() from a root process internally.

C code like Apache changes the user after startup using the setuid() call, which allows it to run on port 80 without serving pages as root. Java doesn’t support this (what a surprise!) so Tomcat for instance can’t do it. This is one of the reasons Tomcat runs on 8080 and most “real” systems run Apache on the front end.

Kev

#5

The standard approach (and officially encouraged) is to put your server on a high port and then configure the linux firewall to redirect the low port to the high port.

e.g. redirect all traffic on port 80 to port 8080

This has a huge security benefit (which is probably partly why its recommended): if you ever forget to install the firewall, or the firewall gets switched off, your server will appear to stop responding :). You will very quickly get told by all your users that something is wrong.

There are other ways of de-securing the ports by faffing about with the kernel (heck, you’ve got the source - you can recompile!) but you almost certainly don’t want to go there :slight_smile:

PS: I think kev meant “running su beforehand”, because su is something you run first (“switch user”) but sudo is something where you have to prefix it to the command you actually want to run (“Switch User, and DO this:” IIRC is what it stands for)

#6

Yeah, what he said. :slight_smile:

Kev

#7

So when using Kevs approach I’d have to make some JNI calls I guess…

But Blah*3h’s approach is much nicer, although I don’t really want to learn firewalls by trial-and-error, when working remotely through SSH. The risk to lock myself out is rather high :persecutioncomplex:

#8

Running network services as a non-root user.:
http://www.debian-administration.org/articles/386

#9

Thanks!