探索Java应用程序安全需求2

在我们继续讲下去之前，应该讲一下如何激活ProfilingSecurityManager ，使之成为应用程序安全管理器。回想前面，我们通过设置一个无对应属性值的系统属性Djava.security.manager来促使应用程序在缺省的Java安全管理器限制下运行。我们需要进一步推广这种措施，并通过给系统属性赋值将定制安全管理器指定为安全管理器：Djava.security.manager=secmgr.ProfingSecurityManager。因此被激活之后，ProfilingSecurityManager将写入System.out，策略文件中需要的这些规则允许应用程序在无需抛出安全违反异常的情况下运行。然而，这些规则不能被处理成最终可用的形式，直到应用程序在ProfilingSecurityManager下完成其运行为止。为什么呢?因为我们知道仅在那时应用程序才完成了以检查资源为目的的请求访问。所以为了使应用程序在ProfilingSecurityManager下完成运行时处理并整理这些规则，我们提供了一个简单的Perl脚本parsecodebase.pl(见 示例代码)，以便以易于阅读的格式聚集、格式化、输出由代码库分类并组合的规则。

　　好了，我们现在用指定为安全管理器的ProfilingSecurityManager 和由parsecodebase.pl处理的规则输出来运行简单的 PrintHome 程序，会产生如下结果：

$ java -cp .:lib/psm.jar -Djava.security.manager=secmgr.ProfilingSecurityManager PrintHome > raw.out 　　$ parsecodebase.pl < raw.out > policy.txt 　　$ cat policy.txt 　　grant codeBase "file:/home/cid/Projects/CustomSecurityManager/" { 　　permission java.util.PropertyPermission "user.home", "read"; 　　}; 　　$ java -cp . -Djava.security.manager -Djava.security.policy=policy.txt PrintHome 　　/home/cid

　　我们再次看到，ProfilingSecurityManager同时满足了我们的两个设计目标：

• 　　我们的应用程序使用定义良好、特定于应用程序的策略在安全管理器下运行
• 　　我们通过编程的方式确定了那个策略

　　ProfilingSecurityManager是如何工作的呢?ProfilingSecurityManager重写了java.lang.SecurityManager 的 checkPermission 方法的两个版本。这个方法的两种形式是用于检查应用程序请求访问哪个资源或活动的中央枢纽。被重写的checkPermission方法总是不需丢弃异常而返回——本意是“允许访问”—不过条件是它们必须建立并输出规则，以允许为其操作负责的活动能首先得到调用。

　　一个更复杂的例子：剖析Tomcat Web应用程序

　　先将那个简单实例暂且搁置，我们来观察ProfilingSecurityManager的一个复杂应用：剖析Tomcat Web应用程序。通过传送 -security 选项到标准启动脚本，Tomcat可在默认Java安全管理器下运行：

$ $CATALINA_HOME/bin/startup.sh -security

　　传送 -security 选项到startup.sh 会导致对拥有同样-security 选项的$CATALINA_HOME/bin/catalina.sh 的调用。$CATALINA_HOME/bin/catalina.sh 实际上是调用Java来运行Tomcat 引导类org.apache.catalina.startup.Bootstrap 的一种脚本，在这种情况下，将进一步受到$CATALINA_HOME/conf/catalina.policy中所规定默认策略的限制。如果我们将调用停留在此处，Tomcat将在由默认提供策略所限制的默认Java安全管理器下运行。不过为了剖析Tomcat以及它可能包含的Web应用程序，我们需要稍微多做一些工作。为了用ProfilingSecurityManager剖析Web应用程序，我们必须开发新的Tomcat启动脚本。新启动脚本是一个临时设备，而且仅用于剖析，之后被废弃。

　　为 $CATALINA_HOME/bin/catalina.sh做一个备份副本。在脚本顶部附近的 $CATALINA_HOME/bin/catalina.sh 中近插入shell命令set -x ,然后启动Tomcat。保存显示的shell执行命令到一个包含临时启动脚本的文件中。停止Tomcat，编辑临时脚本，指定ProfilingSecurityManager 为安全管理器并修改类路径来定位它。

　　以下是在Linux操作系统下的Tomcat 5.5.17中，我们为使用 ProfilingSecurityManager进行编辑之前的临时启动脚本，略经调整和格式化。

#!/bin/sh 　　log=$CATALINA_HOME/logs/catalina.out 　　/java/jdk/jdk1.5.0_06/bin/java \ 　　-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ 　　-Djava.util.logging.config.file=/home/tomcat/tomcat/conf/logging.properties \ 　　-Djava.endorsed.dirs=/home/tomcat/tomcat/common/endorsed \ 　　-classpath :/home/tomcat/tomcat/bin/bootstrap.jar:\ 　　/home/tomcat/tomcat/bin/commons-logging-api.jar \ 　　-Djava.security.manager \ 　　-Djava.security.policy==/home/tomcat/tomcat/conf/catalina.policy \ 　　-Dcatalina.base=/home/tomcat/tomcat \ 　　-Dcatalina.home=/home/tomcat/tomcat \ 　　-Djava.io.tmpdir=/home/tomcat/tomcat/temp \ 　　org.apache.catalina.startup.Bootstrap start >> $log \ 　　2>&1 &

为了使用 ProfilingSecurityManager而进行编辑后，该启动脚本如下所示：

#!/bin/sh 　　log=$CATALINA_HOME/logs/catalina.out 　　PATHTOPSM=$HOME/lib/psm.jar # make sure the profiler jar file is here 　　/java/jdk/jdk1.5.0_06/bin/java \ 　　-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ 　　-Djava.util.logging.config.file=/home/tomcat/tomcat/conf/logging.properties \ 　　-Djava.endorsed.dirs=/home/tomcat/tomcat/common/endorsed \ 　　-classpath $PATHTOPSM:/home/tomcat/tomcat/bin/bootstrap.jar:\ 　　/home/tomcat/tomcat/bin/commons-logging-api.jar \ 　　-Djava.security.manager=secmgr.manager.ProfilingSecurityManager \ 　　-Djava.security.policy==/home/tomcat/tomcat/conf/catalina.policy \ 　　-Dcatalina.base=/home/tomcat/tomcat \ 　　-Dcatalina.home=/home/tomcat/tomcat \ 　　-Djava.io.tmpdir=/home/tomcat/tomcat/temp \ 　　org.apache.catalina.startup.Bootstrap start >> $log \ 　　2>&1 &

　　这两个脚本的不同点在于新临时版本：

• 　　增加了类路径以指向ProfilingSecurityManager类的位置，即$HOME/lib/psm.jar 中
• 　　在-Djava.security.manager参数中指定ProfilingSecurityManager为安全管理器

　　现在我们可以开始剖析了。用临时启动脚本启动 Tomcat 。促使相关web应用程序覆盖那些会在生产中被覆盖的代码，以此考验它们的速度。用代码覆盖Web应用程序是一个公认的、难以实现的命令，而且可能仅有部分可以实现。停止Tomcat，通过parsecodebase.pl运行$CATALINA_HOME/logs/catalina.out ，如下所示，同时将处理过的规则保存到到 policy.txt中。

$ parsecodebase.pl < $CATALINA_HOME/logs/catalina.out > policy.txt

　　清单 9. 处理由Tomcat和其中所包含的任意已执行Web应用程序生成的规则

　　注意 ProfilingSecurityManager只能为那些在剖析过程中执行的代码生成规则。它会探测理论上可以在随机运行实例中触及的所有代码分支，而不检查类文件中的字节码。这样的字节码分析可能是将来的一个研究领域，我们将加以补充，但它不能替换由 ProfilingSecurityManager 做的运行时分析。

　　对随Tomcat提供的策略文件 $CATALINA_HOME/conf/catalina.policy 的检查表明，Tomcat ("Catalina")系统代码库获得了所有平台的权限。事实上，ProfilingSecurityManager会发现Tomcat系统类的这些相同规则，但会以细粒度的方式指定它们。ProfilingSecurityManager发现的关于Tomcat系统类的规则应从policy.txt中手动删除。

　　删除了 Tomcat系统规则后，仍然保留在policy.txt中的规则就是生产安全策略的起点。这些规则表示Web应用程序的安全需求。应仔细检查这些规则中的每一条，以了解其用途，并确保它与我们的应用程序目标相一致。确信有好的草案策略时，为$CATALINA_HOME/conf/catalina.policy做一个备份副本，并从 policy.txt中将新草案规则整合进来。然后用-security 选项集回复到原来的 Tomcat 启动脚本，继续测试。

　　结束语

　　在Java安全管理器下运行应用程序可以增加代码的健壮性。而且，虽然获得安全策略制订权是一项艰巨的挑战，不过这样做会让我们安心，因为代码将在我们所规定的安全约束的限制下运行。ProfilingSecurityManager可以为我们提供对应用程序所请求访问的资源集的充分可见度，从而帮助我们获得策略制订权。