Re: allowing ordinary users to open privileged ports
Herman Sheremetyev <[email protected]> Sun, 12 Sep 2004 12:41:43 -0400
| Newsgroups | gmane.comp.security.sun,gmane.spam.detected |
|---|---|
| Message-ID | <1095007303.4483.19.camel@djinn> |
Have you looked at the jakarta commons-daemon? http://jakarta.apache.org/commons/daemon/jsvc.html I'm not sure how well it would work in your case but I've gotten it to run tomcat as non-root user on linux bound to port 80. -Herman On Sat, 2004-09-11 at 13:45, randy calma repasa wrote: > I would like to thank everyone who have shared their suggestions, > experiences, document links, etc... to my problem at hand. Please allow > me to summarize: > > 1. Use ndd -set /dev/tcp tcp_smallest_nonpriv_port [ < 1024 ]. Ndd > however, does not allow the value to be below 1024 (whether from > runlevel 1 or runlevel 2) like Casper Dik said. I may have read > somewhere that there is a header file somewhere that allows us to define > this parameter value to be lower, i am looking for links or documents > that could point me to this file's location. > I was planning on closing the security hole left by lowering the > smallest non-privileged port with the tcp_extra_priv_ports_add paremeter > for every port < 1024; except for the port i want open for the java > application. > > 2. Setting the setuid bit (chmod 6751) on the application launcher > (a shell script actually which starts the java application) and then > chown(ing) the file to root. This left me with a licensing issue that > would require an abnormally long amount of time to resolve with the > application developers (at the moment it will not start unless the > licensing is changed or added for user root), plus the uncertainty of > not knowing whether the application can and should be run as root. The > application uses (and was developed for) an ordinary account to start > and run. > > 3. Setting the setuid bit on the application launcher and running > the script as root with the file owners environment variables. No dice. > I thought this would have the intended effect of temporarily gaining > root's all powerful blessing and allow the application to bind to my > target port. Silly me. > > A little background for those suggesting port mapping/port forwarding: > > The java application normally uses two ports for communication with > the clients: one for normal and one for encrypted traffic. Setting which > ports to use upon application startup is done using configuration files > at the application $HOME direcroty. For clients to be able to use the > application, they point to a URL hosted in the server (at port 80); > download the java client (which is automatic) and communicate with the > server application using the ports specified at configuration. The java > client shares the server application's port settings. > > Ipf (or port forarding/port mapping tools) would provide an > excellent solution if the client's ports are independent from that of > the servers application's, however they are not. > > The reason for the client's request to have the application use port > 443 is that it is the only port they can open at the firewall to allow > the application's traffic. The server application is hosted at our > server, while they initially point to their browsers to application's > web launcher and then launch the java client from there. They have > denied requests for the application's ports to be allowed through the > firewall (call them finicky and paranoid, call me frustrated). > > Right now i am still trying to find ways to solve the problem. I > will appreciate any and further suggestions that this list's experience > can lend me. > > Thank you very much and best regards. > > Randy >