Re: allowing ordinary users to open privileged ports

I'm glad to hear that your method #2 presented other problems
which prevented you from using it.

Creating a setuid shell script creates a major security hole.
Local users with access to such a script can execute arbitrary
programs as the owner of the script (root in this case).

Re:
> From: "randy calma repasa" <[email protected]>
> To: <[email protected]>
> Subject: allowing ordinary users to open privileged ports
> Date: Sun, 12 Sep 2004 01:45:07 +0800
> 
> 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