Craig R. McClanahan wrote:
Unix (and Linux) provide mechanisms to deal with this already, without
changing the root-only restriction for ports < 1024.

* There's a system call to change your user id (this is what
  Apache itself does to grab port 80 as root and then switch
  itself to a non-privileged user before actually doing anything
  else.)  Doing something like this for Tomcat is technically
  feasible, but will require a bit of native code and some tweaks
  to the way that the TCP connectors are started up.

* There's utilities like ipchains that can automatically forward
  port 80 connections to some other port (such as one that's not
  privileged), and optionally implement firewall type access controls
  as well.

* You can create a "chroot" environment that limits the scope of
  things the process can actually get to, even though it thinks it
  is running as root.

There's no need to change the root-only restriction to solve this
"problem".  Adequate mechanisms are already there to accomplish what you
need.  Use them.
Just to clarify things a bit, before I ask for a new feature in Tomcat. Most "security conciencious" servers on UNIX (like BIND 9) use this sequence:

1. Bind to TCP ports
2. Load all dynamic modules, libraries (usually done by the loader)
3. chroot()
4. setuid()

This way the server process cannot wlak out of chroot-jail, even if it is hacked. I've seen two kinds of problems with this setup, so far. Step-1 usually doesn't bind to syslog's socket and some implementations have a fixed location of this file ("/dev/log"). Any such need would fail. Step-2, in case of AMaViS-new, can ommit some of the modules (AMaViS is a Perl based daemon and the new branch has chroot ability).

So, the questions are:

- will any of these steps be problematic for Tomcat?
- this is not supported by Java, so only UNIX-like OSes will have it?

Nix.


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to