The typical java web application is fronted by a web server (usually Apache) for a number of reasons. Apache handles static content well, and also is easier to configure to listen on privileged ports (under 1024). I’ve written before about different options for connecting Tomcat and Apache, but there are times when all you need is a servlet engine, and installing Apache is overkill. If you don’t want users to see a nonstandard port in their url (http://foo.com:8080/webapp/), then you have a couple of options.
You can run tomcat as root. This is probably not a good idea, since anyone who can write a jsp can now execute arbitrary commands as root. I don’t know how Tomcat’s security is, but in general, the fewer applications running with super user privileges, the better.
If you share my dislike of Tomcat running as root, here’s an excellent rundown of the options for running Tomcat on port 80. I went the route of jsvc. This seemed to work just fine, though every time we shut down tomcat, we would get an entry in the error log file: jsvc.exec error: Service exit with a return value of 143.
That didn’t start to disturb me until I realized that the destroy method of our servlets weren’t being called. This method cleaned up after the servlet and it was important that it get executed. A bit of googling turned up a discussion of this very problem. The version of jsvc that ships with Tomcat 5.0.27 doesn’t shut down Tomcat very nicely.
I downloaded and compiled subversion, because that’s the version control system that the daemon jakarta project (of which jsvc is a part) used. I then checked out the version of the source tagged daemon-1_0_1 (svn co http://svn.apache.org/repos/asf/jakarta/commons/proper/daemon/tags/daemon-1_0_1/) and rebuilt jsvc. This new version allows tomcat to call the destroy methods of servlets, and everything seems to be happy.
Follow me on Twitter
Follow me on Blue Sky
The consensus on the interweb might be against running tomcat as root, but I have to say that I think you’re /they’re wrong and are just scaremongering. People say that it’s a bad idea but no one has any concrete reasons. I can’t find any examples anywhere on the interweb of tomcat being compromised from an external source. I’m not talking about dodgy JSP content run by a generic hosting provider, but a private website. And certainly not for any recent versions.
As a small example, I’ve been running tomcat as root on port 80 for about 4 years without any noticeable problems…
Hi Paul,
I’m not sure I’m scaremongering. I think I’m just applying the priniciple of letting any application have the permissions that it needs and no more. There’s no real reason to run any application as root, other than ease of installation/use.
Do you run all your commands as the root user on your web server? If not, then you’re applying a similar principle (give users the permissions they need and no more).
Here’s a list of the tomcat 5 security fixes: http://tomcat.apache.org/security-5.html Not all of them are scary, but some are a bit concerning (directory traversal).
Here’s the security focus vulnerablilty list: http://www.securityfocus.com/bid ; choose Apache Software Foundation as the vendor and you can see a number of vulnerabilities.
Don’t forget that tomcat runs on the JVM, which has its own vulnerabilities too.
Of course, you need to weigh the pros and cons of each approach. If it is a personal, private website, then the chances of someone wanting to take the effort of breaking in (or finding a script that does so), then the chances are low. (I’m glad you’ve encountered no security breaches in the last 4 years!) If you’re running a big site, or one that handles money, then the chances are higher, and it might be worth the extra effort.
Thanks Dan, I’m glad that you’ve given me the opportunity to get into this…
On the whole I do run as administrator on machines I’m working on, especially windows boxes. Typing sudo all the time is a pain, and in my (limited) experience, most sysadmins do too. You can’t really perform much serious administration if you’re not root.
I’m familiar with the Apache Tomcat 6.x vulnerabilities page, and I think that perhaps you’re confusing general application vulnerabilities with those specifically relating to privilege escalation (countered by not running as root). XSS attacks are independent of privilege level and can’t attack the host server OS directly. So are web server information disclosure attacks. I’m obviously ruling out all the vulnerabilities that relate to deploying web applications. Clearly if you’re messing with tomcat’s internals then you can mess it up. Just as installing mod_crashit into apache web server would. That’s what I meant by private web sites – one’s where the public can’t deploy webapps, as you might on a hosting service. I didn’t mean a site about my cat 🙂
That leaves one elevated privileges item that again requires messing with tomcat’s logging implementation which you can’t do if you don’t have other access to the server, or the ability to deploy webapps. Let me be clear, I’m not saying that tomcat is perfectly secure. I’m just saying that I can’t see a specific problem running it as root.
I have to finish with, again, that I cannot find one documented external privilege escalation attack successfully mounted anywhere on the interweb…
Hi Paul,
I agree that XSS vulnerabilities don’t count as a reason not to run Tomcat6 as root. I do think that directory traversal exploits are a reason not to run tomcat as root, since root can go places (and read files) on a system that the ‘nobody’ user can’t (if the exploit lets you out of the webroot).
I looked through the security focus list, and I agree, I didn’t see a whole lot of Tomcat exploits. I did see at least one scary java exploit (arbitrary code execution):
http://www.securityfocus.com/bid/28125/discuss
This could affect tomcat (depending on what webapps are deployed).
I’m not a security guy, but I asked some colleagues who specialize in security what they think. I’ll let you know if they respond.
Thanks Dan,
I’d find it very useful to get some expert feedback. I think that this is an important issue to explore due to the seeming lack of detailled argument on the interweb.
So many people struggle setting up tomcat with all sorts of connectors, jails, port redirects, etc. It might just be that they don’t need to…
Hi Paul,
One security guy wrote back:
“No point in privilege escalation if I can already inject some code and get the service to run it as root. Game over man. That said I typically see tomcat run as root. Probably worth priv sep’n it on high profile web facing content, but many admins don’t bother.
So, I guess you could say if you control all the executable content in the tomcat tree and it is all known, trusted, and can’t be changed you could relatively safely run as root/admin. That is until some new exploit in your stack comes out…”
I know it can be a pain, but I try to avoid running as root unless I absolutely need to. When I surf on my Windows box, it is as a locked down user account. That way I don’t have to worry about whether or not something tries to install on the back end. If I really need something installed I’ll just use “runas”. Any time you run something as root you are taking a risk, however unlikely, that someone or some worm out there is going to pwn your box.
Another way to run on port 80 without root privileges is to use authbind. This article describes how to install and configure it: http://java-notes.com/index.php/installing-tomcat-with-http-port-80-on-linux .
I never needed the destroy method so didn’t test it, but since Tomcat is not touched is any way with the authbind approach (except the 8080->80 of course), I have to assume we’ll also avoid the ignored destroy-method issue…