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…

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’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…

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.

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…

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.