On Linux do people chroot a Java Web Application or use IPTables and run as non-root?

Question

When you run a Java Servlet Container that you would like to serve both static and dynamic content on port 80 you have the classic question of whether to run the server as:

1. As root in hopefully a chroot jail if you can (haven't gotten this working yet)
2. As a non root user and then use IPTables to forward port 80 to some other port (>1024) that the container is running on
3. Both: As a non root user, IPTables, and chroot jail.

The problem with opt. 1 is the complexity of chrooting and still the security problems of running root.The problem with opt. 2 is that each Linux distro has a different way of persisting IPTables. Option 3 of course is probably idea but very hard to setup.

Finally every distro has the annoying differences in daemon scripts.

What do people find as the best distro agnostic solution and are there resources to show how to do this?

EDIT: I would rather not run Apache in front of the servlet container because the site is mostly dynamic and total memory footprint is important (hosting costs).

Christinachristine

Another option is to use Apache and mod_jk. – Crepuscular

I have done performance testing against the "proxy" approach and if you serve mostly dynamic content its slower to use a proxy. – Christinachristine

Similar question on serverfault: serverfault.com/questions/124537/… – Christinachristine

Another option is using the xinetd super service: ibm.com/developerworks/java/library/l-secjav.html – Christinachristine

Answer 1

Run as non-root and use a standard webserver (apache) or a lightweight one (such as lighttpdor nginx) on port 80 to redirect to your instance.

This has the advantage that the standard webserver can serve static content, reducing the load on your web application. You could even have it reverse-proxy and cache the web application traffic.

Haya

The problem is that the proxy incurs a bandwidth latency cost not to mention you now need to be running multiple servers (apache and servlet container) so you need a more powerful server with more memory. – Christinachristine

@Adam, have you tried proxying with nginx or lighttpd as opposed to Apache? I've never used lighttpd, but nginx has excellent performance and has a very small memory footprint. Of course, a proxy will always add to the latency, but with nginx it's a small amount compared to Apache. – Turgent

@Turgent I'll have to look into nginx. The only issue I can imagine is that nginix probably does not have the same level of support that apache and mod_jk. – Christinachristine

I think you'll find the latency is minimal, and the resources required are actually reduced. Don't make assumptions - test it out. – Haya

Answer 2

Check out authbind, which is designed specifically to allow non-root users controlled access to privileged ports.

This way, you can effectively escalate your Tomcat user's privileges to just the root powers you want (open privileged ports) without giving your webapp process unnecessary powers to wreak havoc.

Orangery

Answer 3

I use jetty on port 8080 and redirect with

iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

Robey

that is my normal approach to this problem. However I still have to write the annoying init/daemon scripts to make sure that that iptables command gets run and jetty/tomcat gets started. – Christinachristine

Answer 4

The recently found vulnerability in Struts2 - https://www.imperva.com/blog/2017/03/cve-2017-5638-new-remote-code-execution-rce-vulnerability-in-apache-struts-2/ - shows clearly that running as root is dangerous.

Griseofulvin

Answer 5

why not simply run it as root? what bad can happen?

I've never heard of a java servlet container being hacked and the hacker can break out of JVM and gains access to OS.

Let's say that happens. The hacker read the JVM code and found a hole. He breaks into your system through your servlet container and logs in as the user that runs the servlet container.

then you are screwed. the most valueable and the only valueable things on your server are all accessible to that user. it doesn't matter that the user is a normal user.

what more damage can be done if that user is root? OS is disposable, just wipe it clean and reinstall.

Mathes

Detecting that a machine has been compromised becomes significantly more difficult if the attacker has root access. – Salaidh

if the attacker is after your app data, a restricted user account won't help at all. if the attacker hijacks the machine to do something else, big deal. in any case, it is infinitely impossible that the attacker breaks in through a http port opened in a JVM. there are much easier ways. – Mathes

1) "infinitely impossible": I do not think that phrase means what you think it means. 2) Detection: If root access is not gained, intrusion can be detected through HID services, and you know it is time to restore from a known clean backup. If root access is gained, the compromise could well be undetected, ongoing, and may cost much more to recover from (if you ever figure it out) – Mulvihill

actually one of the advantages I like about not running it as root is that I can give access to other developers and not worry about them installing emacs-or-their-favorite-unix-program. It also makes it easy to see all the processes that are running that are "ours" and not OS userland processes like syslog. – Christinachristine