CN102955915A

CN102955915A - 一种Java应用安全访问控制方法及其装置

Info

Publication number: CN102955915A
Application number: CN2011102444304A
Authority: CN
Inventors: 李勇; 吴恒; 胡睿
Original assignee: China Mobile Communications Group Co Ltd
Current assignee: China Mobile Communications Group Co Ltd
Priority date: 2011-08-23
Filing date: 2011-08-23
Publication date: 2013-03-06
Anticipated expiration: 2031-08-23
Also published as: CN102955915B

Abstract

本发明公开一种Java应用安全访问控制方法及其装置，该方法包括：JVM根据Java归档文件中的权限描述信息，生成扩展安全访问策略文件，所述扩展安全策略文件中的组件的资源访问权限信息中设置有授权约束条件，所述授权约束条件表示当对应组件调用其它指定组件的指定操作时需要被赋予被调用组件的资源访问权限；当JVM接收到第一组件调用第二组件的请求且相应组件已经加载时，JVM根据所述扩展安全访问策略文件，若判断本次调用满足相应授权约束条件，则根据相应授权约束条件将第二组件的资源访问权限赋予第一组件，并对本次调用进行安全访问控制。采用本发明可提高Java安全机制部署的灵活性，并能保证在安全控制范围内满足用户访问需求。

Description

一种Java应用安全访问控制方法及其装置

技术领域

本发明涉及通信技术领域，尤其涉及一种Java应用安全访问控制方法及其装置。

背景技术

Java语言具有与平台无关性的特点，使得Java技术目前得到广泛应用。自从Java技术出现以来，有关Java平台的安全性及由Java技术发展所引发的新的安全性问题，引起了越来越多的关注。

Java应用服务器能为Java应用程序提供运行环境，并使用安全机制来保障应用服务器的安全性。Java应用服务器的安全机制主要目的在于：阻止某些未授权的用户调用某些危险的组件(如类、jar包)，并允许授权的用户调用这些组件。具体来说，Java应用服务器的安全机制根据需求实现了不同的功能，比如：

-阻止未授权用户程序创建子进程或者子线程；

-阻止未授权用户程序通过创建socket(套接字)和其他进程进行通信；

-阻止未授权用户对文件系统执行写操作，并且只能对文件系统中有限的资源执行读操作。

传统的Java安全机制包括SecurityManager(安全管理器)和JAAS(JavaAuthentication and Authorization Service，Java验证和授权API)，分别从两个不同的角度实现Java的安全机制。其中，SecurityManager通过判断代码来源，控制哪些来源的代码可以访问哪些敏感资源，从而保护代码执行者的安全性；JAAS通过判断代码执行者的身份，从而判断哪些身份的用户可以访问哪些敏感资源。

传统的Java安全机制分两个层面实现，在部署层面通过类加载器(classloader)对某些类的加载来保证安全性；在运行阶段通过Java的访问控制机制来实现。

Java的访问控制机制基于的数学模型是一个三元组<subject，object，action>，其中，subject代表角色，object代表资源，action代表拥有的权限集，如<user，/home/text.txt，read>表示某一个用户user对/home目录下的text.txt文件具有read的权限。三元组在计算机中可以用二维访问数组来表示，典型的二维访问数组如下表1所示：

表1、二维访问数组

	Object1	Object2
			Subject1	Read，Write	Read
Subject2	Write	Read
			Subject3	Read	Read，Write

下面分别介绍SecurityManager和JAAS。

SecurityManager通过*.policy策略文件(默认的策略文件保存在％jre_home％\lib\security目录中)来生成存储二维访问数组的数据结构。典型的policy文件采用如下格式编写：

grant[codebase]{

permission FilePermission d:\java_resource\*read，write；

}；

其中，Grant和permission为policy文件的关键字；codebase相当于三元组中的subject；FilePermission表示权限所属的类型；d:\java_resource\*相当于三元组中的object，支持通配符*，表示目录下的所有文件；read，write相当于三元组中的action，表示代码对d:\java_resource目录下所有的文件具有read(读)和write(写)的权限。

SecurityManager通过此配置文件生成一个数据结构，Java通过此数据结构存储policy文件配置的规则，然后根据栈检测来判断某一个操作是否有权限。比如假设类A，B，C的权限集分别为A_set，B_set，C_set，并存在此调用关系：类A调用类B的do_something()方法，类B的此方法又调用类C的readFile(“text.txt”)方法，类C的此方法读写本地磁盘文件text.txt。JVM(JavaVirtual Machine，Java虚拟机)中的调用栈如图1所示，JVM判断类C的方法readFile()是否有权限读写text.txt文件，是通过将调用栈中的A，B，C三个类的权限集取交集，并判断A_set∩B_set∩C_set的结果是否有读写text.txt的权限。如果有权限，则应用程序继续正常执行，否则抛出安全异常SecurityException。

JAAS(Java Authentication Authorization Service)也是Java安全机制中的一种，它强调的是通过验证谁在运行代码以及它的权限来保证系统免受用户的攻击。

传统的Java安全访问控制机制正是通过SecurityManager类实现了基于源代码的访问控制，通过JAAS SecurityManager类实现了基于主题(subject)的访问控制，两者共同提高了Java的安全性。

传统的Java安全机制SecurityManager在进行操作之前，通过栈检测对操作相关类的权限集取交集，然后判断某项操作是否有必要的权限执行。然而这种机制存在缺陷，尤其是在用户使用PaaS云平台提供的服务时。这种情况发生在当一个subject_a调用另一个subject_b的操作以完成自身的功能时，被调用的subject_b肯定具有必要的权限来执行所需的任务，但是一般来说subject_a没有必要的权限，因此如果使用SecurityManager进行访问控制，用户的访问服务的请求就可能会因为没有权限被拒绝，最终将导致PaaS云平台提供给用户的服务无法正常调用。

JAAS在一定程度上解决的了传统的SecurityManager机制存在的问题。在前面提到的场景中，JAAS通过将subject_b的操作提升为特权操作，当享有特权时，该操作就不需要调用它的subject_a具有一样的特权，因此subject_b的操作就可以对资源进行全面的访问。然而，JAAS存在的问题是不够灵活，要使某个类的某个操作享有特权，就必须编写特定的代码，调用JAAS提供的接口，因此会造成代码的紧耦合，导致后续的维护比较麻烦。比如，开放PaaS平台的需求经常会发生变化，采用这种硬编码的方式可能会导致在需求变化的时候不得不修改代码，重新编译、部署，代价比较大。另外，PaaS云平台提供的一些供用户程序调用的服务使用的是第三方软件，其中一些第三方软件只是做到了功能上的实现，没有考虑安全机制的问题，并且不提供源代码，这就导致试图通过修改源代码使其在被调用时提升为享有特权的操作变得异常的困难。

由此可见，传统的Java安全机制中的SecurityManager，有可能导致用户的访问服务的请求就因为没有权限被拒绝，而JAAS在部署上又不灵活，尤其对于PaaS云平台来说，在技术实现上有较大障碍。因此亟需一种能够实现灵活部署而又能在安全控制范围内满足用户访问需求的Java安全机制。

发明内容

本发明实施例提供一种Java应用安全访问控制方法及其装置，用以提高Java安全机制部署的灵活性，并能保证在安全控制范围内满足用户访问需求。

本发明实施例提供的Java应用安全访问控制方法，包括：

JVM根据Java归档文件中的权限描述信息，生成扩展安全访问策略文件，所述扩展安全策略文件中的组件的资源访问权限信息中设置有授权约束条件，所述授权约束条件表示当对应组件调用其它组件时需要被赋予被调用组件的资源访问权限；

当JVM接收到第一组件调用第二组件的请求且相应组件已经加载时，JVM根据所述扩展安全访问策略文件，若判断本次调用满足相应授权约束条件，则根据相应授权约束条件将第二组件的资源访问权限赋予第一组件，并对本次调用进行安全访问控制。

本发明实施例提供的用于实现Java应用安全访问控制的JVM，包括：

类加载器，用于加载用户类；

安全管理器，用于根据Java归档文件中的权限描述信息，生成扩展安全访问策略文件，所述扩展安全策略文件中的组件的资源访问权限信息中设置有授权约束条件，所述授权约束条件表示当对应组件调用其它组件时需要被赋予被调用组件的资源访问权限；以及，当接收到第一组件调用第二组件的请求且相应组件已经加载时，根据所述扩展安全访问策略文件，若判断本次调用满足相应授权约束条件，则根据相应授权约束条件将第二组件的资源访问权限赋予第一组件，并对本次调用进行安全访问控制。

本发明的上述实施例，通过扩展现有的安全访问策略文件，使其组件资源访问权限信息中设置有授权约束条件，这样，当JVM接收到一组件调用另一组件的请求时，JVM可根据该扩展安全访问策略文件，在判断该调用满足授权约束条件时，将被调用组件的资源访问权限赋予调用组件，并通过栈检测对该调用进行安全访问控制，从而提高了Java安全机制部署的灵活性，即，可根据需要通过设置相应的授权约束条件来达到为调用组件赋予特殊资源访问权限的目的；另一方面，JVM对调用组件进行安全访问控制，保证了在安全控制范围内满足用户访问需求。

附图说明

图1为现有技术中的JVM中的调用栈示意图；

图2为本发明实施例提供的Java安全控制机制部署阶段的流程示意图；

图3为本发明实施例提供的Java安全控制机制运行阶段的流程示意图；

图4为本发明实施例提供的JVM的结构示意图；

图5为本发明实施例中的服务平台以及JVM之间的关系示意图；

图6A为本发明实施例中的应用程序调用示意图；

图6B为本发明实施例中的调用栈示意图。

具体实施方式

PaaS云平台是指在一台计算机上运行多个程序，需要一种机制能保证用户程序之间不会相互影响。本发明实施例提出了一种防止用户程序之间相互影响的安全沙箱技术。在安全沙箱的限制范围内，用户可以执行任何权限允许的操作。当用户尝试执行安全沙箱限制外的操作时，将抛出安全异常。

通常，安全沙箱机制包括许多功能，例如限制用户程序写文件系统、创建socket、创建子进程或子线程、执行一些系统调用等等。

本发明实施例通过扩展传统policy的描述能力来实现一种全新的Java访问控制机制。本发明实施例提供的安全沙箱技术，结合了Java访问控制机制中SecurityManager和JAAS的优点，并弥补了两者存在的缺陷，为PaaS云平台提供了行之有效的安全沙箱机制。在本发明实施例实现的安全沙箱机制下，不仅能够保证PaaS云平台提供的服务能被用户程序正常的调用，而且能保证PaaS云平台自身的灵活性，以适应平台多变的需求。

与传统的Java安全控制机制相同，本发明实施例提供的Java安全控制机制也分两个层面实现，在部署层面通过类加载器(classloader)对类的加载来保证安全性；在运行阶段通过Java的访问控制机制来实现。具体的，本发明实施例分别从应用的部署阶段和运行阶段实现了安全沙箱机制。在部署阶段，通过配置白名单，改写JVM中类加载器来对用户程序载入的类进行限制；在运行阶段，通过扩展policy策略文件的描述能力，引入JAAS机制中的特权操作概念，实现运行期的访问控制，并且其灵活性也能满足PaaS云平台需求多变的特征。

首先，对应用部署阶段和应用运行阶段进行说明：部署阶段是指将磁盘上的物理资源(比如class文件，即类文件)加载到内存中的过程；运行阶段是指应用程序从开始执行到程序退出之间的过程。JVM采用了滞后加载的类加载机制，即在程序运行时根据需要，在调用某个类的时候将这个类从物理磁盘加载到内存中。因此可以说程序的部署阶段是穿插在运行阶段之中的。

下面对这两个阶段的具体实现进行详细描述。

(1)部署阶段

本发明实施例通过修改JVM的类加载器来限制类的载入。主要的流程可如图2所示，包括：

步骤201，应用程序调用某个类，如调用该类的某个方法。

步骤202，类加载器判断此类是否之前已经被载入到内存中了，如果没有，则转入步骤203，否则继续执行应用程序，如执行被调用的类的相应方法。

步骤203，JVM调用类加载器，以便加载此类的class文件。

步骤204，类加载器判断待加载的类是否在白名单中，如果在白名单中，则转入步骤205；若不在白名单中，则转入步骤206。

所谓“白名单”即为允许加载的类的列表。在具体实施时，可通过jar包名加上类名的方式唯一标识一个类。白名单可预先设置，其中存储有类标识，白名单中的类均认为是允许加载的类。类加载器可通过该唯一标识判断待加载的类是否在白名单中。

步骤205，类加载器将此类加载到内存中，并返回主程序继续执行，如执行被调用的类的相应方法。

步骤206，类加载器拒绝加载此类，抛出异常(如返回操作异常响应)。

通过以上流程可以看出，本发明实施例通扩展程序部署阶段类加载器的能力，通过设置白名单的方式，类加载器有效限制了应用程序可以加载的类的列表。

(2)运行阶段

本发明实施例对policy策略文件的描述能力进行了扩展，实现了带约束条件的隐式授权，一个典型的扩展后的策略文件如下所示：

扩展后的policy策略文件对传统格式进行了如下扩展：

Permission条目中增加了约束条件，通过嵌套{}的形式扩展。如上所示，当且仅当用户类myClass调用ClassB的accessResource()方法，或者调用ClassC的accessResource()方法时，用户类myClass具有ClassB或ClassC的资源访问权限，如读写d:\resource目录下所有资源的权限。若用户类myClass不调用这两个类的accessResource()操作，则用户类myClass仅有读d:\resource目录下所有资源的权限，而没有写权限。

通过此扩展，policy策略文件描述了一种带约束的隐式权限授予机制，即，为用户类赋予资源访问特权(如读写权限)时是有附带约束条件的，仅当用户类的调用符合该约束条件时，才能将被调用的用户类的资源访问特权赋给该调用用户类，从而通过扩展policy策略文件的描述能力来实现灵活的运行时访问控制机制。

根据以上原则，在制定访问权限时，可为需要对资源进行读写的类(如上述的ClassB或ClassC)设置较高的资源访问权限，即特权权限，并在policy策略文件中需要调用该类的用户类(如上述的myClass)的Permission条目中以调用关系的方式设置授权约束条件，以便在符合该调用关系时将被调用的类的特权权限赋予给调用用户类(如上述的myClass)。

通常，SecurityManager的运行机制包括：在JDK(Java Development Kit，Java开发工具包，JDK包括了Java运行环境，Java工具和Java基础的类库)的一些类的实现中，在每个涉及对敏感资源的访问操作前，都通过SecurityManager对象和policy策略文件的规则，判断操作是否有足够的权限，如果有，则继续访问敏感资源，否则抛出安全异常SecurityException。

本发明实施例依然遵循上述SecurityManager的运行机制，以jar包为单位，根据每个jar包的权限描述文件自动生成扩展的policy策略文件，然后由扩展SecurityManager类来根据扩展的policy策略文件的规则判断某个调用操作对敏感资源是否有足够的访问权限。

在应用程序执行之前，根据应用程序的类依赖文件，即每个jar包的权限描述，生成扩展policy策略文件。

其中，每个jar包对其包含的所有类的权限有一个整体的描述。描述由两部分组成，一部分是jar包所有类默认具有的权限，另一部分是jar包中哪些类的哪些方法是特权方法，这些特权方法有哪些额外的权限。

通过读取jar包，可获得权限描述信息，然后将jar包描述文件里的所有特权操作及其具有的额外权限赋给所有用户类，需要说明的是，对用户类的隐式权限授予是带约束条件的，从而生成扩展的policy策略文件。进一步的，还可根据扩展policy策略文件初始化得到SecurityManager权限检测的数据结构。此数据结构与现有技术中的数据结构不同的是，其中包含了扩展policy策略文件中的约束条件。

在应用程序运行期间，当应用程序执行用户类的调用操作，且该用户类或/和被调用的类已经加载的情况下，本发明实施例提供的安全访问控制流程可如图3所示，通常情况下，用户自定义的类具有最小的权限集originalPermissionSet。其中，为描述方便，以用户类myClass调用ClassA的accessResource()方法，欲读写d:\java_resource目录下的resource.data资源文件为例进行描述。其中，用户类myClass具有读d:\java_resource目录下的所有文件的权限，ClassA具有读写d:\java_resource目录下的所有文件的权限，该流程可包括：

步骤301，SecurityManager根据policy策略文件判断用户类myClass是否有访问被调用类ClassA的访问权限，如果有，则转入步骤302；否则转入步骤306。

在具体实施时，SecurityManager可根据由扩展policy策略文件判断用户类myClass是否有访问被调用类ClassA的访问权限。

步骤302，SecurityManager根据policy策略文件判断用户类myClass调用ClassA的accessResource()方法的操作是否满足授权约束条件，如果满足，则转入步骤303；否则，转入步骤304。

在具体实施时，SecurityManager可根据由扩展policy策略文件初始化得到SecurityManager权限检测的数据结构，判断用户类myClass对ClassA的accessResource()方法的调用是否满足授权约束条件。

步骤303，SecurityManager将ClassA的资源访问权限赋给用户类myClass。由于ClassA具有访问d:\java_resource目录下的所有文件的权限，因此用户类myClass也就具有了问d:\java_resource目录下的所有文件的权限，然后转入步骤304。

步骤304，SecurityManager进行栈检测，判断用户类myClass调用ClassA的accessResource()方法的操作是否有足够权限访问资源，如果有，则转入步骤305；否则，转入步骤306。

其中，SecurityManager可根据现有方式进行栈检测，即通过将调用栈中的类的权限集取交集，并判断取交集的结果是否有读写被访问资源的权限。如果有权限，则应用程序继续正常执行，否则抛出安全异常SecurityException。

步骤305，执行被调用的用户类的方法，访问资源。

步骤306，SecurityManager抛出异常。

上述流程中，若JVM在接收到用户类myClass调用ClassA的accessResource()方法的请求时，发现用户类myClass或ClassA还未加载，则先要加载相应类，此后的安全控制流程可如图3所示。用户类的加载可使用前述的类加载过程，当然也可以采用现有加载方式。

以上流程中，应用程序开始执行之前，首先根据应用程序的Jar包生成扩展的policy策略文件，然后根据格式扩展后的policy策略文件来初始化SecurityManager后续权限检测需要用到的数据结构。在程序开始执行之后，扩展后的SecurityManager类首先判断用户类的调用是否满足约束条件进行隐式的权限授予，如果满足则对用户类进行隐式权限授予操作。然后SecurityManager开始进行传统的栈检测以判断操作是否有足够的权限。从而实现了运行阶段的访问控制。

为了更清楚的描述本发明，下面以一具体实例对本发明实施例的具体实现过程进行描述。

本实例中，JVM根据jar包的权限描述信息所生成的policy策略文件中包括：

其中，ClassB、ClassC和ClassD均有对d:\java_resource目录下的所有文件进行读写的权限。

当JVM接收到用户类myClass调用ClassB.accessResource()的请求，以请求访问资源“d:\java_resource\*”时，根据Permission条目下设置的资源访问的授权约束条件，判断出用户类myClass调用ClassB.accessResource()的操作满足该授权约束条件，根据该判断结果JVM将ClassB的资源访问权限赋给用户类myClass，从而使用户类myClass具有对资源“d:\java_resource\*”的读写访问权限，此后JVM按照现有方式通过栈检测，判断此调用操作是否有足够权限访问资源。

当JVM接收到用户类myClass调用ClassD.accessResource()的请求，以请求访问资源“d:\java_resource\*”时，根据Permission条目下设置的资源访问的授权约束条件，判断出用户类myClass调用ClassD.accessResource()的操作不满足该授权约束条件，根据该判断结果JVM不会将ClassD的资源访问权限赋给用户类myClass，此后按照现有方式通过栈检测，判断此调用操作是否有足够权限访问资源。

需要说明的是，以上流程以“类”为例描述，但本发明实施例并不仅限于此种组件，还适用于其它类型的组件，如jar包。

通过以上描述可以看出，本发明实施例扩展了传统Java的访问权限验证流程，通过从部署到运行两个层次，控制类的加载和特定类对资源的访问，实现了灵活可配置的安全沙箱机制。本发明实施例可应用在PaaS云服务平台，从而有效实现平台的安全性。本发明实施例与现有的利用Java传统安全机制提供的SecurityManager和JAAS实现的安全沙箱相比，将JAAS中特权操作的概念和SecurityManager策略文件的灵活性相结合，实现了灵活可配置的安全沙箱机制。

基于相同的技术构思，本发明实施例还提供了一种Java应用安全访问控制装置，该装置可以是JVM，可通过计算机程序实现。

参见图4，为本发明实施例提供的JVM的结构示意图，该JVM可包括：

类加载器401，用于加载用户类；

安全管理器402，用于根据Java归档文件中的权限描述信息，生成扩展安全访问策略文件，所述扩展安全策略文件中的组件的资源访问权限信息中设置有授权约束条件，所述授权约束条件表示当对应组件调用其它组件的指定操作时需要被赋予被调用组件的资源访问权限；以及，当接收到第一组件调用第二组件的请求且相应组件已经加载时，根据所述扩展安全访问策略文件，若判断本次调用满足相应授权约束条件，则根据相应授权约束条件将第二组件的资源访问权限赋予第一组件，并对本次调用进行安全访问控制。

进一步的，安全管理器402还可用于：若判断本次调用不满足授权约束条件，则通过栈检测对本次调用进行安全访问控制。

进一步的，安全管理器402可通过以下方式，在组件的资源访问权限信息中设置授权约束条件：在所述扩展安全策略文件中的第一组件的资源访问权限条目下，设置调用第二组件的指定操作的语句，用于表示当第一组件调用第二组件的指定操作时需要被赋予第二组件的资源访问权限。

进一步的，类加载器401具体用于：当JVM接收到组件调用其它组件的请求后判断相应组件还未加载时，判断相应组件是否存在于允许加载的组件列表中，并当判断为是时，加载所述相应组件。

上述组件可以是用户类。

图5示出了用户、服务平台以及本发明实施例的Java安全访问控制机制(由JVM实现)之间的关系示意。如图所示，本发明实施例的Java安全访问控制机制运行在PaaS云服务平台上，该安全访问控制机制根据policy策略文件、类加载白名单来限制用户程序访问平台的敏感资源。用户程序的各种操作都需要经过访问控制机制验证通过后才能访问平台的敏感资源。

其中，如图6A所示，用户程序通过调用SDK来调用PaaS云服务平台提供的云能力服务(如Database，socket等)。SDK是Software Development Kit的英文缩写，即软件开发工具包，一般是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。用户程序可通过调用SDK提供的API(Application Programming Interface，应用程序接口)来调用PaaS云服务平台提供的云能力服务。图6B示出了调用栈结构，其中，权限交集＝用户类∩SDK∩云能力服务。

本发明的上述实施例，将Java访问控制中的JAAS和SecurityManager的优点结合起来，实现了灵活可配置的安全沙箱机制。相对于JAAS，本发明实施例更具灵活性，通过配置文件而不是硬编码的方式实现访问控制，降低了后续代码维护的复杂性；相对于SecurityManager，本发明实施例通过特权操作的概念使用户类在调用特权操作时能够扩展自身的权限集，达到正常访问PaaS平台提供的云服务的功能。

本发明实施例可应用在PaaS云服务平台的应用托管服务器上，不仅能在有效限制用户程序对平台敏感资源的访问权限的同时保证云平台的服务能被正常调用，并且降低了PaaS云服务平台提供商的维护复杂性和成本。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备(可以是手机，个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。

Claims

1.一种Java应用安全访问控制方法，其特征在于，包括：

Java虚拟机JVM根据Java归档文件中的权限描述信息，生成扩展安全访问策略文件，所述扩展安全策略文件中的组件的资源访问权限信息中设置有授权约束条件，所述授权约束条件表示当对应组件调用其它组件的指定操作时需要被赋予被调用组件的资源访问权限；

2.如权利要求1所述的方法，其特征在于，还包括：

若JVM判断本次调用不满足授权约束条件，则通过栈检测对本次调用进行安全访问控制。

3.如权利要求1所述的方法，其特征在于，JVM通过以下方式，在组件的资源访问权限信息中设置授权约束条件：

在所述扩展安全策略文件中的第一组件的资源访问权限条目下，设置调用第二组件的指定操作的语句，用于表示当第一组件调用第二组件的指定操作时需要被赋予第二组件的资源访问权限。

4.如权利要求1所述的方法，其特征在于，当JVM接收到第一组件调用第二组件的请求，但判断相应组件还未加载时，还包括：

JVM判断相应组件是否存在于允许加载的组件列表中，并当判断为是时，加载所述相应组件。

5.如权利要求1-4之一所述的方法，其特征在于，所述组件为用户类。

6.一种用于实现Java应用安全访问控制的JVM，其特征在于，包括：

类加载器，用于加载用户类；

安全管理器，用于根据Java归档文件中的权限描述信息，生成扩展安全访问策略文件，所述扩展安全策略文件中的组件的资源访问权限信息中设置有授权约束条件，所述授权约束条件表示当对应组件调用其它组件的指定操作时需要被赋予被调用组件的资源访问权限；以及，当接收到第一组件调用第二组件的请求且相应组件已经加载时，根据所述扩展安全访问策略文件，若判断本次调用满足相应授权约束条件，则根据相应授权约束条件将第二组件的资源访问权限赋予第一组件，并对本次调用进行安全访问控制。

7.如权利要求6所述的JVM，其特征在于，所述安全管理器还用于，若判断本次调用不满足授权约束条件，则通过栈检测对本次调用进行安全访问控制。

8.如权利要求6所述的JVM，其特征在于，所述安全管理器具体用于，通过以下方式，在组件的资源访问权限信息中设置授权约束条件：在所述扩展安全策略文件中的第一组件的资源访问权限条目下，设置调用第二组件的指定操作的语句，用于表示当第一组件调用第二组件的指定操作时需要被赋予第二组件的资源访问权限。

9.如权利要求6所述的JVM，其特征在于，所述类加载器具体用于，当JVM接收到组件调用其它组件的请求后判断相应组件还未加载时，判断相应组件是否存在于允许加载的组件列表中，并当判断为是时，加载所述相应组件。

10.如权利要求6-9之一所述的方法，其特征在于，所述组件为用户类。