Return-Path: X-Original-To: apmail-tomcat-dev-archive@www.apache.org Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 17E60E6EB for ; Wed, 5 Dec 2012 20:23:03 +0000 (UTC) Received: (qmail 26319 invoked by uid 500); 5 Dec 2012 20:23:00 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 26238 invoked by uid 500); 5 Dec 2012 20:23:00 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 26205 invoked by uid 99); 5 Dec 2012 20:23:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Dec 2012 20:23:00 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Dec 2012 20:22:56 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id AADCF2388CAE for ; Wed, 5 Dec 2012 20:21:13 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1417624 [34/38] - in /tomcat/site/trunk/docs/tomcat-8.0-doc: ./ api/ appdev/ appdev/sample/ appdev/sample/docs/ appdev/sample/src/ appdev/sample/src/mypackage/ appdev/sample/web/ appdev/sample/web/WEB-INF/ appdev/sample/web/images/ archite... Date: Wed, 05 Dec 2012 20:21:01 -0000 To: dev@tomcat.apache.org From: rjung@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20121205202113.AADCF2388CAE@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Added: tomcat/site/trunk/docs/tomcat-8.0-doc/security-howto.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/tomcat-8.0-doc/security-howto.html?rev=1417624&view=auto ============================================================================== --- tomcat/site/trunk/docs/tomcat-8.0-doc/security-howto.html (added) +++ tomcat/site/trunk/docs/tomcat-8.0-doc/security-howto.html Wed Dec 5 20:20:35 2012 @@ -0,0 +1,388 @@ +Apache Tomcat 8 (8.0.0-dev) - Security Considerations

+      The Apache Tomcat Servlet/JSP Container
+

Apache Tomcat 8

Version 8.0.0-dev, Dec 5 2012
Apache Logo

Links

User Guide

Reference

Apache Tomcat Development

Security Considerations

Table of Contents
+ +
Introduction
+

Tomcat is configured to be reasonably secure for most use cases by + default. Some environments may require more, or less, secure configurations. + This page is to provide a single point of reference for configuration + options that may impact security and to offer some commentary on the + expected impact of changing those options. The intention is to provide a + list of configuration options that should be considered when assessing the + security of a Tomcat installation.

+ +

Note: Reading this page is not a substitute for reading + and understanding the detailed configuration documentation. Fuller + descriptions of these attributes may be found in the relevant documentation + pages.

+
Non-Tomcat settings
+

Tomcat configuration should not be the only line of defense. The other + components in the system (operating system, network, database, etc.) should + also be secured.

+

Tomcat should not be run under the root user. Create a dedicated user for + the Tomcat process and provide that user with the minimum necessary + permissions for the operating system. For example, it should not be possible + to log on remotely using the Tomcat user.

+

File permissions should also be suitable restricted. Taking the Tomcat + instances at the ASF as an example (where auto-deployment is disabled and + web applications are deployed as exploded directories), the standard + configuration is to have all Tomcat files owned by root with group Tomcat + and whilst owner has read/write priviliges, group only has read and world + has no permissions. The exceptions are the logs, temp and work directory + that are owned by the Tomcat user rather than root. This means that even if + an attacker compromises the Tomcat process, they can't change the + Tomcat configuration, deploy new web applications or modify existing web + applications. The Tomcat process runs with a umask of 007 to maintain these + permissions.

+

At the network level, consider using a firewall to limit both incoming + and outgoing connections to only those connections you expect to be + present.

+
Default web applications
+

Tomcat ships with a number of web applications by default. + Vulnerabilities have been discovered in these applications in the past. + Applications that are not required should be removed so the system will not + be at risk if another vulnerability is discovered.

+
Security manager
+

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.

+
server.xml
+
General
+

The default server.xml contains a large number of comments, including + some example component definitions that are commented out. Removing these + comments makes it considerably easier to read and comprehend + server.xml.

+

If a component type is not listed, then there are no settings for that + type that directly impact security.

+
+ +
Server
+

Setting the port attribute to -1 disables + the shutdown port.

+

If the shutdown port is not disabled, a strong password should be + configured for shutdown.

+
+ +
Listeners
+

The APR Lifecycle Listener is not stable if compiled on Solaris using + gcc. If using the APR/native connector on Solaris, compile it with the + Sun Studio compiler.

+ +

The Security Listener should be enabled and configured as appropriate. +

+
+ +
Connectors
+

By default, an HTTP and an AJP connector are configured. Connectors + that will not be used should be removed from server.xml.

+ +

The address attribute may be used to control which IP + address the connector listens on for connections. By default, the + connector listens on all configured IP addresses.

+ +

The allowTrace attribute may be used to enable TRACE + requests which can be useful for debugging. Due to the way some browsers + handle the response from a TRACE request (which exposes the browser to an + XSS attack), support for TRACE requests is disabled by default.

+ +

The maxPostSize attribute controls the maximum size + of a POST request that will be parsed for parameters. The parameters are + cached for the duration of the request so this is limited to 2MB by + default to reduce exposure to a DOS attack.

+ +

The maxSavePostSize attribute controls the saving of + POST requests during FORM and CLIENT-CERT authentication. The parameters + are cached for the duration of the authentication (which may be many + minutes) so this is limited to 4KB by default to reduce exposure to a DOS + attack.

+ +

The maxParameterCount attribute controls the + maximum number of parameter and value pairs (GET plus POST) that can + be parsed and stored in the request. Excessive parameters are ignored. + If you want to reject such requests, configure a + FailedRequestFilter.

+ +

The xpoweredBy attribute controls whether or not the + X-Powered-By HTTP header is sent with each request. If sent, the value of + the header contains the Servlet and JSP specification versions, the full + Tomcat version (e.g. Apache Tomcat/7.0.0), the name of the JVM vendor and + the version of the JVM. This header is disabled by default. This header + can provide useful information to both legitimate clients and attackers. +

+ +

The server attribute controls the value of the Server + HTTP header. The default value of this header for Tomcat 4.1.x, 5.0.x, + 5.5.x, 6.0.x and 7.0.x is Apache-Coyote/1.1. This header can provide + limited information to both legitimate clients and attackers.

+ +

The SSLEnabled, scheme and + secure attributes may all be independently set. These are + normally used when Tomcat is located behind a reverse proxy and the proxy + is connecting to Tomcat via HTTP or HTTPS. They allow Tomcat to see the + SSL attributes of the connections between the client and the proxy rather + than the proxy and Tomcat. For example, the client may connect to the + proxy over HTTPS but the proxy connects to Tomcat using HTTP. If it is + necessary for Tomcat to be able to distinguish between secure and + non-secure connections received by a proxy, the proxy must use separate + connectors to pass secure and non-secure requests to Tomcat. If the + proxy uses AJP then the SSL attributes of the client connection are + passed via the AJP protocol and separate connectors are not needed.

+ +

The ciphers attribute controls the ciphers used for + SSL connections. By default, the default ciphers for the JVM will be used. + This usually means that the weak export grade ciphers will be included in + the list of available ciphers. Secure environments will normally want to + configure a more limited set of ciphers.

+ +

The tomcatAuthentication attribute is used with the + AJP connectors to determine if Tomcat should authenticate the user or if + authentication can be delegated to the reverse proxy that will then pass + the authenticated username to Tomcat as part of the AJP protocol.

+ +

The allowUnsafeLegacyRenegotiation attribute provides + a workaround for + + CVE-2009-3555, a TLS man in the middle attack. This workaround applies + to the BIO connector. It is only necessary if the underlying SSL + implementation is vulnerable to CVE-2009-3555. For more information on the + current state of this vulnerability and the work-arounds available see the + Tomcat 7 security + page.

+ +

The requiredSecret attribute in AJP connectors + configures shared secret between Tomcat and reverse proxy in front of + Tomcat. It is used to prevent unauthorized connections over AJP protocol.

+
+ +
Host
+

The host element controls deployment. Automatic deployment allows for + simpler management but also makes it easier for an attacker to deploy a + malicious application. Automatic deployment is controlled by the + autoDeploy and deployOnStartup + attributes. If both are false, only Contexts defined in + server.xml will be deployed and any changes will require a Tomcat restart. +

+ +

In a hosted environment where web applications may not be trusted, set + the deployXml attribute to false to ignore any + context.xml packaged with the web application that may try to assign + increased privileges to the web application.

+
+ +
Context
+

This applies to Context + elements in all places where they can be defined: + server.xml file, + default context.xml file, + per-host context.xml.default file, + web application context file in per-host configuration directory + or inside the web application.

+ +

The crossContext attribute controls if a context is + allowed to access the resources of another context. It is + false by default and should only be changed for trusted web + applications.

+ +

The privileged attribute controls if a context is + allowed to use container provided servlets like the Manager servlet. It is + false by default and should only be changed for trusted web + applications.

+ +

The allowLinking attribute controls if a context is + allowed to use linked files. If enabled and the context is undeployed, the + links will be followed when deleting the context resources. Changing this + setting from the default of false on case insensitive + operating systems (this includes Windows) will disable a number of + security measures and allow, among other things, direct access to the + WEB-INF directory.

+
+ +
Valves
+

It is strongly recommended that an AccessLogValve is configured. The + default Tomcat configuration includes an AccessLogValve. These are + normally configured per host but may also be configured per engine or per + context as required.

+ +

Any administrative application should be protected by a + RemoteAddrValve. (Note that this Valve is also available as a Filter.) + The allow attribute should be used to limit access to a + set of known trusted hosts.

+ +

The default ErrorReportValve includes the Tomcat version number in the + response sent to clients. To avoid this, custom error handling can be + configured within each web application. Alternatively, the version number + can be changed by creating the file + CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties with + content as follows:

+
+server.info=Apache Tomcat/7.0.x
+      
+

Modify the values as required. Note that this will also change the version + number reported in some of the management tools and may make it harder to + determine the real version installed. The CATALINA_HOME/bin/version.bat|sh + script will still report the version number.

+ +

The default ErrorReportValve can display stack traces and/or JSP + source code to clients when an error occurs. To avoid this, custom error + handling can be configured within each web application.

+
+ +
Realms
+

The MemoryRealm is not intended for production use as any changes to + tomcat-users.xml require a restart of Tomcat to take effect.

+ +

The JDBCRealm is not recommended for production use as it is single + threaded for all authentication and authorization options. Use the + DataSourceRealm instead.

+ +

The UserDatabaseRealm is not intended for large-scale installations. It + is intended for small-scale, relatively static environments.

+ +

The JAASRealm is not widely used and therefore the code is not as + mature as the other realms. Additional testing is recommended before using + this realm.

+ +

By default, the realms do not implement any form of account lock-out. + This means that brute force attacks can be successful. To prevent a brute + force attack, the chosen realm should be wrapped in a LockOutRealm.

+
+ +
Manager
+

The manager component is used to generate session IDs.

+ +

The default entropy value has been shown to generate predictable values + under certain conditions. For more secure session generation, this should + be set to a long string. This is done automatically if the APR/native + library is installed; a random value will be obtained from the APR/native + library.

+ +

The class used to generate random session IDs may be changed with + the randomClass attribute.

+ +

The length of the session ID may be changed with the + sessionIdLength attribute.

+
+
System Properties
+

Setting org.apache.catalina.connector.RECYCLE_FACADES + system property to true will cause a new facade object to be + created for each request. This reduces the chances of a bug in an + application exposing data from one request to another.

+ +

The + org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH and + org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH + system properties allow non-standard parsing of the request URI. Using + these options when behind a reverse proxy may enable an attacker to bypass + any security constraints enforced by the proxy.

+ +

The + org.apache.catalina.connector.Response.ENFORCE_ENCODING_IN_GET_WRITER + system property has security implications if disabled. Many user + agents, in breach of RFC2616, try to guess the character encoding of text + media types when the specification-mandated default of ISO-8859-1 should be + used. Some browsers will interpret as UTF-7 a response containing characters + that are safe for ISO-8859-1 but trigger an XSS vulnerability if interpreted + as UTF-7.

+
web.xml
+

This applies to the default conf/web.xml file and + WEB-INF/web.xml files in web applications if they define + the components mentioned here.

+ +

The DefaultServlet is configured + with readonly set to + true. Changing this to false allows clients to + delete or modify static resources on the server and to upload new + resources. This should not normally be changed without requiring + authentication.

+ +

The DefaultServlet is configured with listings set to + false. This isn't because allowing directory listings is + considered unsafe but because generating listings of directories with + thousands of files can consume significant CPU leading to a DOS attack. +

+ +

FailedRequestFilter + can be configured and used to reject requests that had errors during + request parameter parsing. Without the filter the default behaviour is + to ignore invalid or excessive parameters.

+
General
+

BASIC and FORM authentication pass user names and passwords in clear + text. Web applications using these authentication mechanisms with clients + connecting over untrusted networks should use SSL.

+ +

The session cookie for a session with an authenticated user are nearly + as useful as the user's password to an attacker and in nearly all + circumstances should be afforded the same level of protection as the + password itself. This usually means authenticating over SSL and continuing + to use SSL until the session ends.

+
Comments

Notice: This is not a Q&A section. + The Apache Comments System is explained + here. + Comments should be pointed towards suggestions on improving the documentation + or server, and may be removed again by our moderators if they are either + implemented or considered invalid/off-topic. + Questions on how to manage Apache Tomcat should be directed + to our mailing lists.


+ Copyright © 1999-2012, Apache Software Foundation +
\ No newline at end of file Propchange: tomcat/site/trunk/docs/tomcat-8.0-doc/security-howto.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: tomcat/site/trunk/docs/tomcat-8.0-doc/security-howto.html ------------------------------------------------------------------------------ svn:keywords = Author Date Id Revision Added: tomcat/site/trunk/docs/tomcat-8.0-doc/security-manager-howto.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/tomcat-8.0-doc/security-manager-howto.html?rev=1417624&view=auto ============================================================================== --- tomcat/site/trunk/docs/tomcat-8.0-doc/security-manager-howto.html (added) +++ tomcat/site/trunk/docs/tomcat-8.0-doc/security-manager-howto.html Wed Dec 5 20:20:35 2012 @@ -0,0 +1,513 @@ +Apache Tomcat 8 (8.0.0-dev) - Security Manager HOW-TO

+      The Apache Tomcat Servlet/JSP Container
+

Apache Tomcat 8

Version 8.0.0-dev, Dec 5 2012
Apache Logo

Links

User Guide

Reference

Apache Tomcat Development

Security Manager HOW-TO

Table of Contents
+ +
Background
+ +

The Java SecurityManager is what allows a web browser + to run an applet in its own sandbox to prevent untrusted code from + accessing files on the local file system, connecting to a host other + than the one the applet was loaded from, and so on. In the same way + the SecurityManager protects you from an untrusted applet running in + your browser, use of a SecurityManager while running Tomcat can protect + your server from trojan servlets, JSPs, JSP beans, and tag libraries. + Or even inadvertent mistakes.

+ +

Imagine if someone who is authorized to publish JSPs on your site + inadvertently included the following in their JSP:

+
+<% System.exit(1); %>
+
+ +

Every time this JSP was executed by Tomcat, Tomcat would exit. + Using the Java SecurityManager is just one more line of defense a + system administrator can use to keep the server secure and reliable.

+ +

WARNING - A security audit + have been conducted using the Tomcat codebase. Most of the critical + package have been protected and a new security package protection mechanism + has been implemented. Still, make sure that you are satisfied with your SecurityManager + configuration before allowing untrusted users to publish web applications, + JSPs, servlets, beans, or tag libraries. However, running with a + SecurityManager is definitely better than running without one.

+ +
Permissions
+ +

Permission classes are used to define what Permissions a class loaded + by Tomcat will have. There are a number of Permission classes that are + a standard part of the JDK, and you can create your own Permission class + for use in your own web applications. Both techniques are used in + Tomcat.

+ + +
Standard Permissions
+ +

This is just a short summary of the standard system SecurityManager + Permission classes applicable to Tomcat. See + http://java.sun.com/security/ + for more information.

+ +
    +
  • java.util.PropertyPermission - Controls read/write + access to JVM properties such as java.home.
  • +
  • java.lang.RuntimePermission - Controls use of + some System/Runtime functions like exit() and + exec(). Also control the package access/definition.
  • +
  • java.io.FilePermission - Controls read/write/execute + access to files and directories.
  • +
  • java.net.SocketPermission - Controls use of + network sockets.
  • +
  • java.net.NetPermission - Controls use of + multicast network connections.
  • +
  • java.lang.reflect.ReflectPermission - Controls + use of reflection to do class introspection.
  • +
  • java.security.SecurityPermission - Controls access + to Security methods.
  • +
  • java.security.AllPermission - Allows access to all + permissions, just as if you were running Tomcat without a + SecurityManager.
  • +
+ +
+ + +
Tomcat Custom Permissions
+ +

Tomcat utilizes a custom permission class called + org.apache.naming.JndiPermission. This permission + controls read access to JNDI named file based resources. The permission + name is the JNDI name and there are no actions. A trailing "*" can be + used to do wild card matching for a JNDI named file resource when + granting permission. For example, you might include the following + in your policy file:

+
+permission  org.apache.naming.JndiPermission  "jndi://localhost/examples/*";
+
+ +

A Permission entry like this is generated dynamically for each web + application that is deployed, to allow it to read its own static resources + but disallow it from using file access to read any other files (unless + permissions for those files are explicitly granted).

+ +

Also, Tomcat always dynamically creates the following file permissions:

+
+permission java.io.FilePermission "** your application context**", "read";
+
+permission java.io.FilePermission
+  "** application working directory**", "read,write";
+permission java.io.FilePermission
+  "** application working directory**/-", "read,write,delete";
+
+

Where **your application context** equals the folder (or WAR file) under which + your application has been deployed and **application working directory** is the + temporary directory provided to your application as required by the + Servlet Specification.

+ +
+ + +
Configuring Tomcat With A SecurityManager
+ +

Policy File Format

+ +

The security policies implemented by the Java SecurityManager are + configured in the $CATALINA_BASE/conf/catalina.policy file. + This file completely replaces the java.policy file present + in your JDK system directories. The catalina.policy file + can be edited by hand, or you can use the + policytool + application that comes with Java 1.2 or later.

+ +

Entries in the catalina.policy file use the standard + java.policy file format, as follows:

+
+// Example policy file entry
+
+grant [signedBy <signer>,] [codeBase <code source>] {
+  permission  <class>  [<name> [, <action list>]];
+};
+
+ +

The signedBy and codeBase entries are + optional when granting permissions. Comment lines begin with "//" and + end at the end of the current line. The codeBase is in the + form of a URL, and for a file URL can use the ${java.home} + and ${catalina.home} properties (which are expanded out to + the directory paths defined for them by the JAVA_HOME, + CATALINA_HOME and CATALINA_BASE environment + variables).

+ +

The Default Policy File

+ +

The default $CATALINA_BASE/conf/catalina.policy file + looks like this:

+ + +
// Licensed to the Apache Software Foundation (ASF) under one or more
+// contributor license agreements.  See the NOTICE file distributed with
+// this work for additional information regarding copyright ownership.
+// The ASF licenses this file to You under the Apache License, Version 2.0
+// (the "License"); you may not use this file except in compliance with
+// the License.  You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+// ============================================================================
+// catalina.policy - Security Policy Permissions for Tomcat 7
+//
+// This file contains a default set of security policies to be enforced (by the
+// JVM) when Catalina is executed with the "-security" option.  In addition
+// to the permissions granted here, the following additional permissions are
+// granted to each web application:
+//
+// * Read access to the web application's document root directory
+// * Read, write and delete access to the web application's working directory
+//
+// $Id$
+// ============================================================================
+
+
+// ========== SYSTEM CODE PERMISSIONS =========================================
+
+
+// These permissions apply to javac
+grant codeBase "file:${java.home}/lib/-" {
+        permission java.security.AllPermission;
+};
+
+// These permissions apply to all shared system extensions
+grant codeBase "file:${java.home}/jre/lib/ext/-" {
+        permission java.security.AllPermission;
+};
+
+// These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre
+grant codeBase "file:${java.home}/../lib/-" {
+        permission java.security.AllPermission;
+};
+
+// These permissions apply to all shared system extensions when
+// ${java.home} points at $JAVA_HOME/jre
+grant codeBase "file:${java.home}/lib/ext/-" {
+        permission java.security.AllPermission;
+};
+
+
+// ========== CATALINA CODE PERMISSIONS =======================================
+
+
+// These permissions apply to the daemon code
+grant codeBase "file:${catalina.home}/bin/commons-daemon.jar" {
+        permission java.security.AllPermission;
+};
+
+// These permissions apply to the logging API
+// Note: If tomcat-juli.jar is in ${catalina.base} and not in ${catalina.home},
+// update this section accordingly.
+//  grant codeBase "file:${catalina.base}/bin/tomcat-juli.jar" {..}
+grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
+        permission java.io.FilePermission
+         "${java.home}${file.separator}lib${file.separator}logging.properties", "read";
+
+        permission java.io.FilePermission
+         "${catalina.base}${file.separator}conf${file.separator}logging.properties", "read";
+        permission java.io.FilePermission
+         "${catalina.base}${file.separator}logs", "read, write";
+        permission java.io.FilePermission
+         "${catalina.base}${file.separator}logs${file.separator}*", "read, write";
+
+        permission java.lang.RuntimePermission "shutdownHooks";
+        permission java.lang.RuntimePermission "getClassLoader";
+        permission java.lang.RuntimePermission "setContextClassLoader";
+
+        permission java.util.logging.LoggingPermission "control";
+
+        permission java.util.PropertyPermission "java.util.logging.config.class", "read";
+        permission java.util.PropertyPermission "java.util.logging.config.file", "read";
+        permission java.util.PropertyPermission "catalina.base", "read";
+        permission java.util.PropertyPermission
+         "org.apache.juli.logging.UserDataHelper.CONFIG", "read";
+        permission java.util.PropertyPermission
+         "org.apache.juli.logging.UserDataHelper.SUPPRESSION_TIME", "read";
+
+        // Note: To enable per context logging configuration, permit read access to
+        // the appropriate file. Be sure that the logging configuration is
+        // secure before enabling such access.
+        // E.g. for the examples web application (uncomment and unwrap
+        // the following to be on a single line):
+        // permission java.io.FilePermission "${catalina.base}${file.separator}
+        //  webapps${file.separator}examples${file.separator}WEB-INF
+        //  ${file.separator}classes${file.separator}logging.properties", "read";
+};
+
+// These permissions apply to the server startup code
+grant codeBase "file:${catalina.home}/bin/bootstrap.jar" {
+        permission java.security.AllPermission;
+};
+
+// These permissions apply to the servlet API classes
+// and those that are shared across all class loaders
+// located in the "lib" directory
+grant codeBase "file:${catalina.home}/lib/-" {
+        permission java.security.AllPermission;
+};
+
+
+// If using a per instance lib directory, i.e. ${catalina.base}/lib,
+// then the following permission will need to be uncommented
+// grant codeBase "file:${catalina.base}/lib/-" {
+//         permission java.security.AllPermission;
+// };
+
+
+// ========== WEB APPLICATION PERMISSIONS =====================================
+
+
+// These permissions are granted by default to all web applications
+// In addition, a web application will be given a read FilePermission
+// and JndiPermission for all files and directories in its document root.
+grant {
+    // Required for JNDI lookup of named JDBC DataSource's and
+    // javamail named MimePart DataSource used to send mail
+    permission java.util.PropertyPermission "java.home", "read";
+    permission java.util.PropertyPermission "java.naming.*", "read";
+    permission java.util.PropertyPermission "javax.sql.*", "read";
+
+    // OS Specific properties to allow read access
+    permission java.util.PropertyPermission "os.name", "read";
+    permission java.util.PropertyPermission "os.version", "read";
+    permission java.util.PropertyPermission "os.arch", "read";
+    permission java.util.PropertyPermission "file.separator", "read";
+    permission java.util.PropertyPermission "path.separator", "read";
+    permission java.util.PropertyPermission "line.separator", "read";
+
+    // JVM properties to allow read access
+    permission java.util.PropertyPermission "java.version", "read";
+    permission java.util.PropertyPermission "java.vendor", "read";
+    permission java.util.PropertyPermission "java.vendor.url", "read";
+    permission java.util.PropertyPermission "java.class.version", "read";
+    permission java.util.PropertyPermission "java.specification.version", "read";
+    permission java.util.PropertyPermission "java.specification.vendor", "read";
+    permission java.util.PropertyPermission "java.specification.name", "read";
+
+    permission java.util.PropertyPermission "java.vm.specification.version", "read";
+    permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
+    permission java.util.PropertyPermission "java.vm.specification.name", "read";
+    permission java.util.PropertyPermission "java.vm.version", "read";
+    permission java.util.PropertyPermission "java.vm.vendor", "read";
+    permission java.util.PropertyPermission "java.vm.name", "read";
+
+    // Required for OpenJMX
+    permission java.lang.RuntimePermission "getAttribute";
+
+    // Allow read of JAXP compliant XML parser debug
+    permission java.util.PropertyPermission "jaxp.debug", "read";
+
+    // All JSPs need to be able to read this package
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.tomcat";
+
+    // Precompiled JSPs need access to these packages.
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.jasper.el";
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.jasper.runtime";
+    permission java.lang.RuntimePermission
+     "accessClassInPackage.org.apache.jasper.runtime.*";
+
+    // Precompiled JSPs need access to these system properties.
+    permission java.util.PropertyPermission
+     "org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER", "read";
+    permission java.util.PropertyPermission
+     "org.apache.el.parser.COERCE_TO_ZERO", "read";
+
+    // The cookie code needs these.
+    permission java.util.PropertyPermission
+     "org.apache.catalina.STRICT_SERVLET_COMPLIANCE", "read";
+    permission java.util.PropertyPermission
+     "org.apache.tomcat.util.http.ServerCookie.STRICT_NAMING", "read";
+    permission java.util.PropertyPermission
+     "org.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR", "read";
+
+    // Applications using Comet need to be able to access this package
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.comet";
+
+    // Applications using WebSocket need to be able to access this package
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.websocket";
+};
+
+
+// The Manager application needs access to the following packages to support the
+// session display functionality. These settings support the following
+// configurations:
+// - default CATALINA_HOME == CATALINA_BASE
+// - CATALINA_HOME != CATALINA_BASE, per instance Manager in CATALINA_BASE
+// - CATALINA_HOME != CATALINA_BASE, shared Manager in CATALINA_HOME
+grant codeBase "file:${catalina.base}/webapps/manager/-" {
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina";
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.ha.session";
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.manager";
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.manager.util";
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.util";
+};
+grant codeBase "file:${catalina.home}/webapps/manager/-" {
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina";
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.ha.session";
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.manager";
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.manager.util";
+    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.util";
+};
+
+// You can assign additional permissions to particular web applications by
+// adding additional "grant" entries here, based on the code base for that
+// application, /WEB-INF/classes/, or /WEB-INF/lib/ jar files.
+//
+// Different permissions can be granted to JSP pages, classes loaded from
+// the /WEB-INF/classes/ directory, all jar files in the /WEB-INF/lib/
+// directory, or even to individual jar files in the /WEB-INF/lib/ directory.
+//
+// For instance, assume that the standard "examples" application
+// included a JDBC driver that needed to establish a network connection to the
+// corresponding database and used the scrape taglib to get the weather from
+// the NOAA web server.  You might create a "grant" entries like this:
+//
+// The permissions granted to the context root directory apply to JSP pages.
+// grant codeBase "file:${catalina.base}/webapps/examples/-" {
+//      permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect";
+//      permission java.net.SocketPermission "*.noaa.gov:80", "connect";
+// };
+//
+// The permissions granted to the context WEB-INF/classes directory
+// grant codeBase "file:${catalina.base}/webapps/examples/WEB-INF/classes/-" {
+// };
+//
+// The permission granted to your JDBC driver
+// grant codeBase "jar:file:${catalina.base}/webapps/examples/WEB-INF/lib/driver.jar!/-" {
+//      permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect";
+// };
+// The permission granted to the scrape taglib
+// grant codeBase "jar:file:${catalina.base}/webapps/examples/WEB-INF/lib/scrape.jar!/-" {
+//      permission java.net.SocketPermission "*.noaa.gov:80", "connect";
+// };
+
+
+ +

Starting Tomcat With A SecurityManager

+ +

Once you have configured the catalina.policy file for use + with a SecurityManager, Tomcat can be started with a SecurityManager in + place by using the "-security" option:

+
+$CATALINA_HOME/bin/catalina.sh start -security    (Unix)
+%CATALINA_HOME%\bin\catalina start -security      (Windows)
+
+ +
Configuring Package Protection in Tomcat
+

Starting with Tomcat 5, it is now possible to configure which Tomcat + internal package are protected againts package definition and access. See + + http://java.sun.com/security/seccodeguide.html + for more information.

+ + +

WARNING: Be aware that removing the default package protection + could possibly open a security hole

+ +

The Default Properties File

+ +

The default $CATALINA_BASE/conf/catalina.properties file + looks like this:

+
+#
+# List of comma-separated packages that start with or equal this string
+# will cause a security exception to be thrown when
+# passed to checkPackageAccess unless the
+# corresponding RuntimePermission ("accessClassInPackage."+package) has
+# been granted.
+package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,
+org.apache.jasper.
+#
+# List of comma-separated packages that start with or equal this string
+# will cause a security exception to be thrown when
+# passed to checkPackageDefinition unless the
+# corresponding RuntimePermission ("defineClassInPackage."+package) has
+# been granted.
+#
+# by default, no packages are restricted for definition, and none of
+# the class loaders supplied with the JDK call checkPackageDefinition.
+#
+package.definition=sun.,java.,org.apache.catalina.,org.apache.coyote.,
+org.apache.tomcat.,org.apache.jasper.
+
+

Once you have configured the catalina.properties file for use + with a SecurityManager, remember to re-start Tomcat.

+
Troubleshooting
+ +

If your web application attempts to execute an operation that is + prohibited by lack of a required Permission, it will throw an + AccessControLException or a SecurityException + when the SecurityManager detects the violation. Debugging the permission + that is missing can be challenging, and one option is to turn on debug + output of all security decisions that are made during execution. This + is done by setting a system property before starting Tomcat. The easiest + way to do this is via the CATALINA_OPTS environment variable. + Execute this command:

+
+export CATALINA_OPTS=-Djava.security.debug=all    (Unix)
+set CATALINA_OPTS=-Djava.security.debug=all       (Windows)
+
+ +

before starting Tomcat.

+ +

WARNING - This will generate many megabytes + of output! However, it can help you track down problems by searching + for the word "FAILED" and determining which permission was being checked + for. See the Java security documentation for more options that you can + specify here as well.

+ +
Comments

Notice: This is not a Q&A section. + The Apache Comments System is explained + here. + Comments should be pointed towards suggestions on improving the documentation + or server, and may be removed again by our moderators if they are either + implemented or considered invalid/off-topic. + Questions on how to manage Apache Tomcat should be directed + to our mailing lists.


+ Copyright © 1999-2012, Apache Software Foundation +
\ No newline at end of file Propchange: tomcat/site/trunk/docs/tomcat-8.0-doc/security-manager-howto.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: tomcat/site/trunk/docs/tomcat-8.0-doc/security-manager-howto.html ------------------------------------------------------------------------------ svn:keywords = Author Date Id Revision Added: tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/index.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/index.html?rev=1417624&view=auto ============================================================================== --- tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/index.html (added) +++ tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/index.html Wed Dec 5 20:20:35 2012 @@ -0,0 +1,34 @@ + + + + + + API docs + + + + +The Servlet Javadoc is not installed by default. Download and install +the "fulldocs" package to get it. + +You can also access the javadoc online in the Tomcat + +documentation bundle. + + + Propchange: tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/index.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/index.html ------------------------------------------------------------------------------ svn:keywords = Author Date Id Revision --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org