-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan-Willem,
On 12/14/11 4:05 AM, jwklomp wrote: > I'm migrating existing applications to Tomcat and setting Tomcat up > as described in the 'Security Configuration Benchmark for Apache > Tomcat 5.5/6.0' of the Center of Internet Security. > > The benchmark recommends enabling the Security Manager. However, > I'm experiencing that none of the apps run 'out of the box' with > the Security Manager enabled. I'm contemplating not activating it, > but find it hard estimate the risk. I'll weigh-in, too, without having read Mark's and Chuck's replies, yet. First, running Tomcat itself under a SecurityManager should work without any problems at all, provided you launch it with the "-security" argument when calling catalina.sh (or whatever method is appropriate for your environment) because the catalina.policy file that ships with Tomcat will allow Tomcat to perform all necessary operations. On the other hand, most non-trivial web app applications need to be able to do a handful of things such as * Connect to a JDBC database * Write log files * Request files from a remote site (think XML DTDs or XSDs) You will be responsible for modifying the catalina.policy file to allow your web application to perform such operations. You may find that configuration is such a headache (there are many permissions, and they tend to pile-up on each other) that the result is a SecurityManager policy that essentially allows all permissions to all code. Such a configuration is no better than having no SecurityManager running at all. In fact, it's worse for two reasons: 1. Performance takes a hit for all the permissions checking that must occur and 2. You are "running a SecurityManager and therefore secure" but you really aren't secure > Our Security department is worried that without the Security > Manager enabled, hackers can gain access to restricted packages, > take control over Tomcat and 'hop' to other applications and > machines (so basically this would imply activating the Security > Manager for all applications). So, it's true that if you restrict your web application to only being able to perform certain operations (such as connecting to a *specific* port on a *specific* server for JDBC connections, and maybe writing to a *specific* directory on your server for logging purposes) you will, in fact, reduce the area of your vulnerable surface that attackers can use to gain access. On the other hand, pretty much everything you can do with a SecurityManager (except maybe resource limits, like preventing new Threads) can be done with other configuration as well (at least, on any relatively decent OS). For example, if you don't want to allow arbitrary outgoing TCP connections, simply configure your firewall that way. If you don't want your webapp to be able to write to anywhere on the filesystem, change your filesystem permissions or run in a chroot jail (or both!). Sure, security should always be considered in layers and it never hurts to have redundant checks just in case you have one layer misconfigured or there is some kind of bug or security vulnerability in a particular layer. But, don't think that you "aren't secure" if you aren't running under a SecurityManager als, likewise, don't think that you "are secure" just because you are running one. Frankly, the most vulnerable part of your web application is likely to be the application itself. SANS' top 25 software errors (should really be "vulnerabilities" IMO) lists mostly things that a SecurityManager won't protect you against (http://www.sans.org/top25-software-errors/). For instance, SQL injection repeatedly tops this list because programmers are sloppy with their parametric SQL statements. SecurityManager can't stop that. OS command injection? If you even allow your webapp to call the OS (Runtime.exec), then SecurityManager can't sanitize the parameters for you. XSS? File Upload? Open Redirect? CSRF? Those are all the fault of the webapp's programmers and cannot be protected against by running a SecurityManager. > My question is: how secure is Tomcat without the Security Manager > enabled (assuming other points from the CIS benchmark have been > implemented). Is the Security Manager the guard against 'hopping' > to other applications, or does Tomcat without the Security Manager > already prevent this? IMO, running a SecurityManager is a nice layer to have, but not strictly necessary. If you are running code that you have written in-house, and you trust your developers not to intentionally introduce nasty code, then you should be relatively safe. If, on the other hand, you are running code that you don't necessary trust, or are allowing untrusted people to deploy their own webapps onto your server, then it is absolutely imperative that you *do* run a SecurityManager, no matter how much of a pain in the ass it is to set up. Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7qGK0ACgkQ9CaO5/Lv0PA8PACdF1ObNFpKxm3SGeqZZI5JF4DL rqUAoKgK5FOEG0OWwK/6cOyTfdEBPAmi =uVMw -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
