在企业数字化转型加速、网络威胁日益复杂的背景下，**安全经理（Security Manager）** 作为组织安全战略的核心执行者

Apache Tomcat 官方文档《Security Manager How-To》 是一份面向系统管理员和开发者的实操指南，核心目的是在 Tomcat 9 中启用并调试 Java SecurityManager，从而对 Web 应用做最小权限管控。下面从“为什么要用、如何启用、如何配置、如何排错、落地建议”五个维度做系统性分析。

1. 为什么要启用 SecurityManager
   • 默认情况下，Tomcat 进程拥有宿主操作系统的全部权限；一旦某个 Web 应用被注入，就可能读写任意文件、执行系统命令或扫描网络。
   • 启用 SecurityManager 后，Tomcat 会在 JVM 级别对每一次敏感操作（文件访问、网络连接、反射、退出 JVM 等）进行权限检查，实现“沙箱”隔离。

2. 启用步骤总览
   ① 准备权限文件
   新建 $CATALIN{A}_{B}ASE/conf/catalina.policy（若已存在则追加）。②修改启动参数在CATALIN{A}_{O}PTS中加入-Djava.security.manager-Djava.security.policy==$CATALINA_BASE/conf/catalina.policy
   ③ 重启 Tomcat。
   ④ 观察日志：若应用缺少权限，会抛出 AccessControlException 或 SecurityException。

3. 关键配置细节
   3.1 catalina.policy 范式
   最简模板：
   grant codeBase “file:${catalina.base}/webapps/yourApp/-” {
   permission java.io.FilePermission “/tmp/-”, “read,write”;
   permission java.net.SocketPermission “db.example.com:5432”, “connect,resolve”;
   };

3.2 常用 JDK 权限类
• java.io.FilePermission – 文件与目录读写执行
• java.net.SocketPermission – 网络连接
• java.lang.RuntimePermission – 控制 System.exit、创建 ClassLoader 等
• java.security.SecurityPermission – 访问安全策略
• java.util.PropertyPermission – 读写 JVM 属性
• java.lang.reflect.ReflectPermission – 反射访问私有成员

3.3 catalina.properties 额外限制
package.access 与 package.definition 两个参数可禁止应用访问/定义某些敏感包（如 sun.、org.apache.catalina.）。

4. 调试与排错
   • 打开详细日志：
   export CATALINA_OPTS=“-Djava.security.debug=all”
   启动后 catalina.out 会打印每一次权限检查结果，搜索 “FAILED” 即可定位缺失的权限。
   • 常见错误示例：
   java.security.AccessControlException: access denied (“java.io.FilePermission” “/opt/data/report.txt” “read”)
   → 在 policy 中追加对应 FilePermission。

5. 落地建议

1. 最小权限原则：不要直接授予 AllPermission；按模块逐步细化。
2. 分阶段实施：先在测试环境打开 SecurityManager，边跑功能测试边补充 policy，再上到生产。
3. 与 CI/CD 集成：将 policy 文件纳入版本控制，变更走代码审核。
4. 定期审计：随着业务迭代，每季度复查权限是否过度。
5. 性能考量：SecurityManager 会带来 2~5% CPU 损耗，对高并发场景需压测验证。

一句话总结
Security Manager How-To 的核心价值是“用最小权限跑 Java Web 应用”。只要遵循“启用→授权→调试→审计”闭环，就能把 Tomcat 装进可控沙箱，显著降低被攻破后的横向移动风险。
在企业数字化转型加速、网络威胁日益复杂的背景下，安全经理（Security Manager） 作为组织安全战略的核心执行者，其角色职责与实战能力直接决定了企业的安全防线强度。《Security Manager How-To》类指南通常聚焦于安全经理的核心工作场景、技能要求与实战方法论，以下从多个维度展开分析。

一、安全经理的核心角色定位

安全经理并非单一的“技术执行者”，而是跨部门安全战略的协调者、风险的把控者、团队的领导者，其核心定位可拆解为：

• 安全战略落地者：将企业高层的安全愿景转化为可执行的政策、流程和技术方案，确保安全目标与业务目标对齐。
• 风险管理者：通过风险评估、漏洞管理、威胁情报分析等手段，识别并优先处理高风险安全隐患，降低组织损失概率。
• 合规负责人：跟踪全球及行业法规（如GDPR、ISO 27001、PCI DSS等），确保企业运营符合法律与合规要求，避免处罚风险。
• 团队领导者：管理安全团队（如安全运营、渗透测试、应急响应等小组），提升团队专业能力，同时协调IT、业务、法务等跨部门协作。
• 安全文化推动者：通过培训、宣传等方式，提升全员安全意识，构建“全员参与”的安全防线。

二、核心工作模块与实战要点

1. 安全策略与制度建设

• 目标：建立覆盖组织全业务流程的安全框架，明确责任与规范。
• 实战步骤：
  • 调研业务场景：识别核心资产（如数据、系统、设备）及潜在威胁（如勒索病毒、数据泄露、内部滥用）。
  • 制定分级策略：根据资产重要性（如“绝密”“机密”“公开”）制定差异化保护措施（如访问控制、加密、备份频率）。
  • 制度落地工具：通过员工手册、培训考核、定期审计确保制度执行（例如：要求全员签署数据安全承诺书，每季度开展合规检查）。

2. 风险评估与漏洞管理

• 目标：主动发现安全薄弱点，优先修复高风险问题。
• 关键方法：
  • 风险评估模型：采用定性（如“高/中/低风险”）与定量（如“风险值=威胁概率×影响程度”）结合的方式，例：某客户数据库泄露的风险值=0.3（威胁概率）×500万（潜在损失）=150万。
  • 漏洞扫描工具：使用Nessus、AWVS等工具定期扫描系统漏洞，重点关注CVSS评分≥9.0的高危漏洞（如Log4j、Heartbleed等）。
  • 修复闭环管理：建立“发现-分配-修复-验证”流程，对未及时修复的漏洞升级至管理层督办（例如：要求72小时内修复高危漏洞，否则暂停相关业务系统使用）。

3. 安全技术体系搭建

• 核心防线：构建“纵深防御”体系，覆盖网络、终端、数据、应用等层面：
  • 网络安全：部署防火墙、入侵检测/防御系统（IDS/IPS）、VPN加密、网络分段（如将办公网与生产网隔离）。
  • 终端安全：安装EDR（终端检测与响应）工具、防病毒软件，启用磁盘加密（如BitLocker），限制U盘等外设使用。
  • 数据安全：对敏感数据（如用户隐私、商业机密）进行分类分级，部署数据防泄漏（DLP）工具，实现“数据全生命周期保护”（采集-存储-传输-使用-销毁）。
  • 应用安全：在开发阶段嵌入SDL（安全开发生命周期），通过代码审计、渗透测试发现应用漏洞（如SQL注入、XSS跨站脚本）。

4. 应急响应与事件处置

• 目标：在安全事件发生后快速止损、降低影响、恢复业务。
• 实战流程（参考NIST框架）：
  • 准备阶段：制定应急响应预案（IRP），明确角色分工（如总指挥、技术分析组、公关组），定期开展桌面演练。
  • 检测阶段：通过SIEM（安全信息与事件管理）平台监控异常日志（如批量登录失败、敏感文件访问异常），快速确认是否为安全事件。
  • 遏制阶段：对受影响系统隔离（如断网、下线），保存证据（如日志、内存镜像），避免威胁扩散（例如：发现勒索病毒时，立即断开感染终端的网络连接）。
  • 根除与恢复：清除恶意代码，修复漏洞，分阶段恢复业务（优先恢复核心系统，如支付系统、客户服务系统）。
  • 总结改进：事后复盘事件原因，更新预案与防护措施（例如：某次勒索事件后，增加异地备份频率至每日一次）。

5. 安全团队管理与能力建设

• 团队架构：根据企业规模配置核心岗位，例如：
  • 小型企业：1-2名安全通才，覆盖策略、技术、应急全领域。
  • 中大型企业：细分安全运营（SOC）、渗透测试、合规审计、安全培训等专项角色。
• 能力提升：
  • 技术培训：鼓励考取CISSP、CISM、CEH等认证，定期开展内部技术分享（如“每周漏洞分析会”）。
  • 跨部门协作：建立与IT部门的“安全需求同步机制”（如新产品上线前需通过安全评审），与业务部门共同制定“业务友好型”安全方案（避免过度防护影响效率）。

三、关键挑战与应对策略

四、总结：优秀安全经理的核心素质

《Security Manager How-To》的本质是指导安全经理实现“从被动防御到主动治理”的转变。优秀的安全经理需具备：

• 技术能力：熟悉主流安全技术与工具，能快速定位并解决问题。
• 战略思维：理解业务目标，将安全转化为企业竞争力（如通过ISO 27001认证提升客户信任）。
• 沟通协调能力：向上争取资源、向下推动执行、跨部门达成共识。
• 持续学习能力：紧跟威胁趋势与法规变化（如《数据安全法》《个人信息保护法》），不断优化安全体系。

通过系统化的策略制定、风险管控、技术落地与团队管理，安全经理可有效构建企业的“安全护城河”，为业务持续发展保驾护航。

Tomcat Home
The Apache Software Foundation
Apache Tomcat 10
Version 10.0.0-M4, Apr 3 2020
Links

Docs Home
FAQ
User Comments

User Guide

1) Introduction
2) Setup
3) First webapp
4) Deployer
5) Manager
6) Host Manager
7) Realms and AAA
8) Security Manager
9) JNDI Resources
10) JDBC DataSources
11) Classloading
12) JSPs
13) SSL/TLS
14) SSI
15) CGI
16) Proxy Support
17) MBeans Descriptors
18) Default Servlet
19) Clustering
20) Load Balancer
21) Connectors
22) Monitoring and Management
23) Logging
24) APR/Native
25) Virtual Hosting
26) Advanced IO
27) Mavenized
28) Security Considerations
29) Windows Service
30) Windows Authentication
31) Tomcat's JDBC Pool
32) WebSocket
33) Rewrite
34) CDI 2 and JAX-RS
35) GraalVM Support

Reference

Release Notes
Configuration
Tomcat Javadocs
Servlet 5.0 Javadocs
JSP 3.0 Javadocs
EL 4.0 Javadocs
WebSocket 2.0 Javadocs
JASPIC 2.0 Javadocs
Annotations 2.0 Javadocs
JK 1.2 Documentation

Apache Tomcat Development

Building
Changelog
Status
Developers
Architecture
Functional Specs.
Tribes

Security Manager How-To
Table of Contents

Background
Permissions
    Standard Permissions
Configuring Tomcat With A SecurityManager
    Permissions for packed WAR files
Configuring Package Protection in Tomcat
Troubleshooting

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://docs.oracle.com/javase/7/docs/technotes/guides/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.

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 ,] [codeBase ] {
permission [ [, ]];
};

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
//
// 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
// ============================================================================

// ========== 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 $JAV{A}_{H}OME/jregrantcodeBase"file:${java.home}/…/lib/-" {
permission java.security.AllPermission;
};

// These permissions apply to all shared system extensions when
// ${java.home} points at $JAV{A}_{H}OME/jregrantcodeBase"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,//updatethissectionaccordingly.//grantcodeBase"file:${catalina.base}/bin/tomcat-juli.jar" {…}
grant codeBase “file:KaTeX parse error: Expected '}', got 'EOF' at end of input: …sion "{java.home}$file.separatorlib${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, delete";

    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";

    permission java.lang.management.ManagementPermission "monitor";

    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 "org.apache.juli.AsyncLoggerPollInterval", "read";
    permission java.util.PropertyPermission "org.apache.juli.AsyncMaxRecordCount", "read";
    permission java.util.PropertyPermission "org.apache.juli.AsyncOverflowDropType", "read";
    permission java.util.PropertyPermission "org.apache.juli.ClassLoaderLogManager.debug", "read";
    permission java.util.PropertyPermission "catalina.base", "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,//thenthefollowingpermissionwillneedtobeuncommented//grantcodeBase"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
// 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.*";

// Applications using WebSocket need to be able to access these packages
permission java.lang.RuntimePermission "accessClassInPackage.org.apache.tomcat.websocket";
permission java.lang.RuntimePermission "accessClassInPackage.org.apache.tomcat.websocket.server";

};

// The Manager application needs access to the following packages to support the
// session display functionality. It also requires the custom Tomcat
// DeployXmlPermission to enable the use of META-INF/context.xml
// 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/-"permissionjava.lang.RuntimePermission"accessClassInPackage.org.apache.catalina";permissionjava.lang.RuntimePermission"accessClassInPackage.org.apache.catalina.ha.session";permissionjava.lang.RuntimePermission"accessClassInPackage.org.apache.catalina.manager";permissionjava.lang.RuntimePermission"accessClassInPackage.org.apache.catalina.manager.util";permissionjava.lang.RuntimePermission"accessClassInPackage.org.apache.catalina.util";permissionorg.apache.catalina.security.DeployXmlPermission"manager";;grantcodeBase"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”;
permission org.apache.catalina.security.DeployXmlPermission “manager”;
};

// The Host Manager application needs the custom Tomcat DeployXmlPermission to
// enable the use of META-INF/context.xml
// These settings support the following configurations:
// - default CATALINA_HOME == CATALINA_BASE
// - CATALINA_HOME != CATALINA_BASE, per instance Host Manager in CATALINA_BASE
// - CATALINA_HOME != CATALINA_BASE, shared Host Manager in CATALINA_HOME
grant codeBase “file:$catalina.base/webapps/host-manager/-"permissionorg.apache.catalina.security.DeployXmlPermission"host-manager";;grantcodeBase"file:${catalina.home}/webapps/host-manager/-” {
permission org.apache.catalina.security.DeployXmlPermission “host-manager”;
};

// 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/-"//permissionjava.net.SocketPermission"dbhost.mycompany.com:5432","connect";//permissionjava.net.SocketPermission"\ast .noaa.gov:80","connect";//;////ThepermissionsgrantedtothecontextWEB-INF/classesdirectory//grantcodeBase"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!/-"//permissionjava.net.SocketPermission"dbhost.mycompany.com:5432","connect";//;//Thepermissiongrantedtothescrapetaglib//grantcodeBase"jar:file:${catalina.base}/webapps/examples/WEB-INF/lib/scrape.jar!/-” {
// permission java.net.SocketPermission “*.noaa.gov:80”, “connect”;
// };

// To grant permissions for web applications using packed WAR files, use the
// Tomcat specific WAR url scheme.
//
// The permissions granted to the entire web application
// grant codeBase “war:file:$catalina.base/webapps/examples.war\ast /-"//;////ThepermissionsgrantedtoaspecificJAR//grantcodeBase"war:file:${catalina.base}/webapps/examples.war*/WEB-INF/lib/foo.jar” {
// };

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)

Permissions for packed WAR files

When using packed WAR files, it is necessary to use Tomcat’s custom war URL protocol to assign permissions to web application code.

To assign permissions to the entire web application the entry in the policy file would look like this:

// Example policy file entry
grant codeBase “war:file:${catalina.base}/webapps/examples.war*/-” {
…
};

To assign permissions to a single JAR within the web application the entry in the policy file would look like this:

// Example policy file entry
grant codeBase “war:file:${catalina.base}/webapps/examples.war*/WEB-INF/lib/foo.jar” {
…
};

Configuring Package Protection in Tomcat

Starting with Tomcat 5, it is now possible to configure which Tomcat internal package are protected against package definition and access. See http://www.oracle.com/technetwork/java/seccodeguide-139067.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.