Re: allowing ordinary users to open privileged ports

From: Brian Parent (bparent_at_calvin.ucsd.edu)
Date: 09/13/04

  • Next message: Ron Ogle: "Solaris 9 authentication and access control into Active Directory" 
    Date: Mon, 13 Sep 2004 10:28:40 -0700
To: focus-sun@securityfocus.com

    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" <rrepasa@ekonek.com>
    > To: <focus-sun@securityfocus.com>
    > 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 *** 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

  • Next message: Ron Ogle: "Solaris 9 authentication and access control into Active Directory"
    • Quantcast