Java应用程序环境的安全策略，详细说明了对于不同的代码所拥有的不同资源的许可，它由一个Policy对象来表达。

为了让applet（或者运行在SecurityManager下的一个应用程序）能够执行受保护的行为，例如读写文件，applet（或Java应用程序）必须获得那项操作的许可,安全策略文件就是用来实现这些许可。 Policy对象可能有多个实体，虽然任何时候只能有一个起作用。 当前安装的Policy对象，在程序中可以通过调用 getPolicy方法得到，也可以通过调用setPolicy方法改变。Policy对象评估整个策略，返回一个适当的Permissions对象，详细说明那些代码可以访问那些资源。 可见 通过配置policy来达到控制SecurityManager，在Applet RMI上面已经见到很大的成效。 但很多现在WEB容器如TOMCAT RESIN等等都通过指导用户配置policy来管理自己JAVA网站的安全。 对于初级hacker 可能会达到一定成效，但是我个人持保留意见。 首先简单看看JAVA WEB容器webapps的管理策略。 每个app都是占用该容器同一进程，而不同于各自的包管理，请求控制都是采用 MultiThread + ClassLoader 的. 所以写serlvet/filter public的属性需要注意并发，而各个webapp都有各自的lib等等。 至于这样的对于安全来说会极其恶心... 问题1: A webapp 调用了 system.exit 导致WEB容器挂了。 问题2: A webapp 因为代码质量问题内存泄露，导致B webapp访问不了。 问题3: webapp 调用 runtime.exec 执行系统命令***操作系统。 而针对以上这些问题，我估计sun应该比较尴尬的了，容器提供商们都只能采用了java自带的操作方法。就是配置policy 如何配置呀？ TOMCAT可以看看 RESIN 可以搜索 <<Resin虚拟主机的java安全沙箱设置>> 基本上就是限制用户操作 java.io java.net java.awt java.runtime java.util ... 但是很遗憾告诉你，这些都是可以bypass的！为什么？因为JAVA里面沙箱限制都是在java class层控制的 而 采用 reflect 可以绕过这些进而操作JNI等等...如何操作可以看这paper 那如果把reflect也同样限制了呢？跟applet一样严格！ OK 现在我们来看看实际情况 首先webapp 常用的框架 spring  ibatis  hibernate 先拿这3个来说。 spring-2.5.6 org.springframework.beans.BeanUtils 的 copyProperties 等方法对一个method需要进行setAccessible hibernate-3.1.3 org.hibernate.util.ReflectHelper 的 getDefaultConstructor 等方法对一个constructor需要进行setAccessible ibatis-2.3.4 com.ibatis.common.beans.ClassInfo 的 addFields等方法需要对一个field 需要进行setAccessible 如果你限制了，就等于不支持这些opensource framework 看了以上的告示，郁闷了吧？ 说了这么多，最后想告诉大家些什么呢？在JAVAWEB容器中 设置policy是靠不住的，只能说是提高了门槛。 对java的运行权限安全配置才是王道。