I would disagree with just about everything you said. Yes, root is like a citadel, and it is for that exact reason that you should take as many steps as necessary to NEVER run publicly accessible services as root. In my opinion, your thinking is exactly backwards. On a properly configured Linux/UNIX server, a generic account can do just about ZERO damage to critical files. A root account can do anything it wants, anytime it wants, anywhere it wants.
If you run a process as root, and a cracker manages to figure out how to exploit a defect in that service to run arbitrary commands, THOSE COMMANDS WILL RUN AS ROOT. This is REALLY BAD, and it's exactly what you DON'T want to happen. If running as root was a good thing, Apache wouldn't fork children running as 'nobody' to handle HTTP requests. Yes, Apache starts as root, but no publicly accessible requests are served as root. If, on the other hand, you run your publicly accessible service as a generic user, and a cracker manages to figure out how to exploit a defect in that service, they will only have the permissions of that user, NOT as root. That is the desired behavior from a security perspective. You should never log in as root via telnet, and you should never log in as root using FTP for those reasons as well. Telnet and FTP send passwords in the clear. Ideally, you would build machines disconnected from any network and lock them down first, then connect them to a network, logging in as root by console only until you get SSH installed and configured. Any machine built while connected to a network can be considered suspect and untrusted unless you know the exact source of all traffic on that network or are willing to lower your standards or risk that someone has snooped your root password all those times you've logged in as root before getting SSH installed. If you run Tomcat as root, you are risking a future exploit (or currently unknown exploit) that will run as root. Bad idea, all around. Java's security model alleviates this risk somewhat, but trusting that model 100% is foolish, especially if you are responsible for business enterprise data like financial information, credit card numbers, intellectual property, or medical information...nothing is perfect. Depending on the contents of the server, and the perimissions that server has with other nodes on your network, running a publicly accessible service can be anywhere from no big deal in the least to severe, dangerous liability in the worst. In a corporate or enterprise network, you not only don't want to EVER run a publicly accessible service (Tomcat or any other) as root, you should also take whatever steps necessary to shut down all other unnecessary services on that machine, some of which run by default (like those running via inetd). For example, if the machine is a webserver, it should have SSH and HTTP enabled, and that's it. Period. Anything else running on a port on that box is a potential hole. Because of connectors needing a port beyond port 80, probably the most secure architecture for Tomcat would be a DMZ with Apache + JK, connecting through a firewall to a Tomcat server on a protected network. The firewall rules would only allow traffic to Tomcat:8009 from the Apache server. Leaving 8009 (or whatever connector port you use) open to the world is asking for trouble....it would be trivial for someone to write a exploit tool that sent random garbage to port 8009 using the AJP13 protocol as a way to see what would happen to Tomcat as a result. If they did (and you can bet someone has done it or is thinking about doing it), and you were running Tomcat as root, you'd be a sitting duck. John > -----Original Message----- > From: Kristjan Rznarsson [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 05, 2002 7:34 AM > To: Tomcat Users List > Subject: Re: Why run tomcat as root > > > "Sanjaya Singharage" <[EMAIL PROTECTED]> > 05.12.2002 10:33 > Please respond to "Tomcat Users List" > > > To: [EMAIL PROTECTED] > cc: > Subject: Why run tomcat as root > > > with respect to security what is the best way to run tomcat > on linux? I am > running tomcat3.2.3 with apache1.3.26 and mod_jk > 1. Run as root? > 2. Run as nobody? > 3.Run as other user (eg. tomcat)? > > why is running tomcat as a certain user more secure than running it as > others? > > For starters if you want to use privileged ports (port<1024) > you must be > root. If you for example want tomcat to listen on ports 80 > (HTTP default > port) or 443 (HTTPS default ports) you must start tomcat as ROOT. > Theoretically of course you can run tomact as user "nobody" > but you will > not be able to use ports<1024. If you use non privileged > ports you will > have to live with the annoyance of every one who wants to access your > server having to suffix the port number to the url > (http://www.|someurl|.org:8080/) with a privileged default > port like 80 > (HTTP) all you have to do is type the URL > (http://www.|someurl|.org). The > Root account is also preferable beacuse the account and > processes that run > under it are considerably better protected than those of a > normal user, > provided you have not castrated the Root account security wise, ie > configured it incorrectly. The less secure the account you run Tomcat > under the easyser it is for a malicious user to sabotage your > webserver by > editing or deleting files, killing processes and so on. The > ROOT acount is > a citadel on a mountain top, very hard for a hacker to break, > much harder > than a normal account. If you run Tomcat as root, only you and those > trusted few that you have mady privy to the root password, > can manipulate > the Tomcat server. > > If this is the appropriate place to ask a question on apache > and tomcat, > what would be the answer to the same question regarding > running apache and > tomcat together. > > Yes. Since the topics overlap I fail to see why it should be > forbidden to > discuss tomact/apache interaction. > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
