If you can dedicate an IP address to this solution (IP alias on your
server), then continue with my ipf solution and just map the privilegded
ports on that one / dedicated IP address to your client's application ports.
As you are needing port 443, does this mean that SSL is the encryption
mechanism with your client's program? If so, you need a separate IP address
anyway as one cannot do name-based virtual web hosting with SSL [but perhaps
I'm reading too much into the fact that port 443 was chosen].
Cheers ... PHil
-----Original Message-----
From: randy calma repasa [mailto:rrepasa@ekonek.com]
Sent: Saturday, September 11, 2004 1:45 PM
To: focus-sun@securityfocus.com
Subject: allowing ordinary users to open privileged ports
Importance: High
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
