Enabling the security manager causes web applications to be run in a sandbox, significantly limiting a web application’s ability to perform malicious actions such as calling System.exit(), establishing network connections or accessing the file system outside of the web application’s root and temporary directories. However, it should be noted that there are some malicious actions, such as triggering high CPU consumption via an infinite loop, that the security manager cannot prevent.
Enabling the security manager is usually done to limit the potential impact, should an attacker find a way to compromise a trusted web application . A security manager may also be used to reduce the risks of running untrusted web applications (e.g. in hosting environments) but it should be noted that the security manager only reduces the risks of running untrusted web applications, it does not eliminate them. If running multiple untrusted web applications, it is recommended that each web application is deployed to a separate Tomcat instance (and ideally separate hosts) to reduce the ability of a malicious web application impacting the availability of other applications.
Tomcat is tested with the security manager enabled; but the majority of Tomcat users do not run with a security manager, so Tomcat is not as well user-tested in this configuration. There have been, and continue to be, bugs reported that are triggered by running under a security manager.
The restrictions imposed by a security manager are likely to break most applications if the security manager is enabled. The security manager should not be used without extensive testing. Ideally, the use of a security manager should be introduced at the start of the development cycle as it can be time-consuming to track down and fix issues caused by enabling a security manager for a mature application.
Enabling the security manager changes the defaults for the following settings:
The default value for the deployXML attribute of the Host element is changed to false.
