Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to achieve some measure of "privilege separation" with Java web-server?

I'm trying to be proactive around security on my Jetty web-server boxes -- especial with regards to storing SSL key information although I'd like a generic solution. Apache uses privilege separation so that it starts as root so it can read the protected SSL key files (and other secure configuration) and then switches to some common user to actually server HTTP requests. But Java has no mechanism for doing this.

Any recommendations around how to achieve the same level of security in a Java web application? My requires include:

  • Secret information should only be readable by root.

  • Any passwords which unlock keys and the like should not be configured into the code so that someone with the same user level permissions as the server can't get them easily.

  • I'm running under Amazon EC2 so I want the security to be as automatic as possible -- i.e. no interactive password entering by operators.

One possibility would be to use ~LDAP to separate the secret information from the application and only bake the LDAP access username/password into the application. But I'm looking for a better solution.

Thanks for any information.

Edit:

I'd hoped for solutions that covered SSL but took into account other secrets that I wanted to limit access to. I did not make that clear enough in my initial post.

like image 252
Gray Avatar asked Apr 17 '13 22:04

Gray


2 Answers

The apache technique you described is provided by the optional jetty-setuid features.

See http://www.eclipse.org/jetty/documentation/current/setuid.html

like image 56
Joakim Erdfelt Avatar answered Sep 30 '22 15:09

Joakim Erdfelt


As soon as you bake anything like a password into source (which is stored on disk), you've circumvented security. So, storing the information in LDAP isn't going to help.

I'm not convinced the setuid feature is going to help either, in that it is there purely for accessing ports in the networking code, and might not do the setuid at the correct time (after opening the SSL files). Of course, you could test that by protecting the files as root and see if it can open them...if so, you're golden and Joakim's answer is the best option.

What we do is set up a simple apache or nginx server to front the JVM through a proxy, then run jetty under it's own UID. Then you can take advantage of the setuid SSL security that is already well-tested in either of those servers. We also have some other requirements that this also helps solve, but I would probably choose to do it this way even if we didn't.

The nginx config is also pretty darn simple:

server {
    listen       192.168.1.1:443;
    server_name  www.mydomain.com;
    index  index.html index.htm;
    root   /usr/share/nginx/html;

    ssl                  on;
    ssl_certificate      /etc/nginx/conf.d/ssl/server.crt;
    ssl_certificate_key  /etc/nginx/conf.d/ssl/server.key;
    access_log  /var/log/nginx/ssl.access.log  main;

    ssl_session_timeout  5m;

    ssl_protocols  SSLv2 SSLv3 TLSv1;
    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers   on;

    location /AppPath {
       proxy_pass http://jettyhost:8080/AppPath;
    }
}
like image 24
Tony K. Avatar answered Sep 30 '22 17:09

Tony K.