本发明涉及移动安全和访问控制领域，更具体地，涉及一种android应用多开环境中限制访问的控制方法及系统。
背景技术
android手机作为个人贴身的手持设备，里面存放着很多个性化的用户隐私数据，这些数据有的产生于用户使用第三方开发的应用过程中，比如登录社交应用的账号、密码，浏览器生成的浏览记录等，还有一些数据例如gps、手机设备id等由android手机本身提供，在原生的android系统上，为确保用户隐私数据的安全性，每一个应用程序以同一个uid的身份运行一个实例，应用与应用之间采用安全沙箱技术进行隔离，安全沙箱的实现基于selinux的强制访问控制，在默认情况下只能访问他们自己的文件和非常有限的系统服务。
但是在一些场景和需求下，很多用户需要在android手机上运行一个应用的多个实例，比如有些用户需要同时使用两个社交账户，一个用于工作，一个用于生活社交，基于这样的需求，目前已有一些手机厂商在其自身手机rom上实现了应用多开的功能，比如华为、小米的应用分身功能等，这种应用多开功能的实现是在操作系统上做了相应改造和升级，安全性较高。但是，在基于android系统本身提供的动态加载技术上，在早期的时候很多第三方开发者利用这种技术实现应用功能的插件化，以此来实现应用的增量更新，避免每次更新的时候让用户下载完整的应用程序包。这种技术逐渐被演化为应用虚拟化技术，即一个应用能够实现加载别的应用在其内部稳定运行，这种功能的实现无需更改系统和应用的字节码，并且被启动运行的应用并不需要真正安装在用户的真实手机上。很多用户在没有应用多开支持的手机情况下，可选择第三方提供的应用多开系统实现应用分身。
针对应用虚拟化的研究，早期bianchi等人(bianchia,fratantonioy,kruegelc,etal.njas:sandboxingunmodifiedapplicationsinnon-rooteddevicesrunningstockandroid,acmccsworkshoponsecurityandprivacyinsmartphonesandmobiledevices,acm,2015:27-38.)通过ptrace的进程注入技术拦截应用调用系统的api，实现一个应用在另外一个应用的上下文环境中运行。这种方式只能实现针对特定应用的虚拟化，且很多应用会ptrace自身进程来抵抗注入。
backes等人(backesm,bugiels,hammerc,etal.boxify:full-fledgedappsandboxingforstockandroid.usenixconferenceonsecuritysymposium,usenixassociation,2015:691-706.)基于android系统提供给的isolatedprocess特殊进程设计了一款应用沙箱，将不受信任的android应用隔离在这种没有任何权限的特殊进程中。这种沙箱的好处是能够隔离危险程序在沙箱中运行，防止危险程序对系统、或者系统上的其他应用造成危害。
据研究发现，现有第三方多开应用的虚拟化核心原理与之前的系统基本类似，都是通过虚拟化系统的核心服务层来做到在一个应用内部运行多个应用的效果，其主要通过实现对系统activitymanagerservice和packagemanagerservice两大基本服务组件的虚拟化，应用所有和activitymanagerservice、packagemanagerservice的交互首先通过中间的虚拟化服务代理层，在虚拟化的服务层完成对应用中各个组件的生命周期管理。但是提供多开服务的应用不可能将具有一定功能的应用运行在这种没有任何权限的isolatedprocess进程中，所以现有的多开宿主应用基本都是以普通进程的方式运行其他应用，被运行的应用和宿主应用具有同样的权限，同时为了支持各种类型应用的稳定运行，宿主应用会申请大量能够满足其他应用运行时使用的权限、组件类型等。但是不管怎样，这些应用之间、应用与宿主应用之间共享同一个uid，然而系统底层是基于用户的访问控制，也就意味着这些应用和宿主应用共享同样的权限、目录。一旦用户在使用过程中不慎在多开环境中加载运行了含有针对多开环境进行恶意攻击的应用程序，恶意程序或者应用中包含的恶意第三方代码将可获得宿主应用申请的所有权限，也就是说应用、应用中所包含的第三方代码和宿主应用拥有同样的权限集合。同时拥有和宿主应用同样的文件系统访问权限，包括对多开环境中其他重要应用文件目录的访问读写，从而造成隐私信息泄露。
综上所述，目前还没有人提出针对多开环境中应用权限进行控制的解决方案，之前的研究主要集中在将恶意应用隔离到受限的环境，也不同于android操作系统上的应用隔离，应用多开环境中的访问控制是针对以单个用户身份运行的多个进程的资源访问控制。鉴于可能造成的危害，势必要有一套机制来缓解应用多开环境中的提权攻击。
技术实现要素：
针对现有技术的缺陷，本发明的目的在于解决现有技术没有提出针对多开环境中应用权限进行控制的解决方案，之前的研究主要集中在将恶意应用隔离到受限的环境，也不同于android操作系统上的应用隔离，应用多开环境中的访问控制是针对以单个用户身份运行的多个进程的资源访问控制，需要有一套机制来缓解应用多开环境中的提权攻击的技术问题。
为实现上述目的，一方面，本发明提供一种android应用多开环境中限制访问的控制方法，设andriod系统中提供虚拟化运行环境的应用为hostapp，hostapp支持andriod系统中的应用在其构建的虚拟化运行环境中运行，设在此虚拟化环境中被加载运行的应用为clientapp，包括：
当clientapp运行时，若当前操作为敏感api调用操作，则结合已加载的策略信息判断当前敏感api调用操作是否合法，若合法则允许该clientapp调用真正的api，否则禁止提权调用；
若当前操作属于文件访问操作，则iohook模块将被触发，获取当前需要访问的文件目录，然后由iocheck模块结合策略库检查当前访问是否合法，若合法则调用真正的系统进行文件操作，否则抛出异常，结束访问；
hostapp在加载clientapp的同时，解析其包含权限清单数据的文件，得到文件中列出的权限清单，作为默认的准许授权集合，再综合开发者的策略配置信息，形成最终的授权集合。
其中，clientapp包含权限清单数据的文件为manifest.xml文件。
可选地，当clientapp运行时，若当前操作为敏感api调用操作，则结合已加载的策略信息判断所述敏感api调用操作是否合法，若合法则允许该clientapp调用真正的api，否则禁止提权调用，包括：
步骤1.1，当clientapp运行时，如果当前操作属于敏感api调用操作，apihook模块将自动被触发并获取当前调用的调用链，通过调用链获取发起此次调用的主体源信息，即修改框架中已有的hook模块，即使用动态代理的技术实现对敏感资源服务的调用端binder进行拦截，hook模块将当前的调用信息发送到远程的vpms；
步骤1.2，vpms首先得到调用发起者的信息，然后vpms将调用pcheck模块，pcheck模块结合policymanager已加载的策略信息判断当前调用是否合法，然后将结果反馈给apihook模块；
步骤1.3，apihook模块根据反馈结果进行校验，如果校验通过则允许调用真正的系统api，否则禁止提权调用。
可选地，步骤1.1具体包括以下子步骤：
步骤1.1.1，clientapp发起敏感api调用请求；
步骤1.1.2，敏感api调用请求被hook代码拦截；
步骤1.1.3，hook代码获取当前调用的敏感api名称、当前clientapp的包名以及进程pid；
步骤1.1.4，hook模块在clientapp所在进程空间的api拦截处创建throwable对象；
步骤1.1.5，通过throwable对象获取系统调用堆栈信息，根据系统调用堆栈信息获取本次调用的发起主体信息即调用源信息；
步骤1.1.6，hook模块将当前调用源信息、调用的敏感api信息、以及当前clientapp的包名、进程pid封装到parcel对象中；
步骤1.1.7，将步骤1.1.6封装后的对象通过vpms的远程代理接口以进程间调用的方式发送至vpms。
可选地，步骤1.2具体包括以下子步骤：
步骤1.2.1，vpms首先从parcel对象中读取当前调用源信息、调用的敏感api信息、以及当前clientapp的包名以及进程pid；
步骤1.2.2，根据权限与api的映射关系，得到调用当前敏感api所需申请的权限名称；
步骤1.2.3，根据clientapp的包名，在策略库中查找相关的策略配置，包括针对clientapp的访问控制策略信息、以及clientapp中包含的第三方代码的访问控制策略信息；
步骤1.2.4，如果当前的调用主体源是不属于策略库当中配置的第三方代码集合，则执行步骤1.2.5，否则执行步骤1.2.8；
步骤1.2.5，根据敏感api所需申请的权限名称和clientapp的包名、准许的访问授权集合，判断当前操作所涉及的权限是否在准许的访问授权集合当中；
步骤1.2.6，如果存在准许的访问授权集合当中，则返回permission_granted；结束步骤1.2；
步骤1.2.7，如果不存在准许的访问授权集合当中，则返permission_denied；结束步骤1.2；
步骤1.2.8，如果当前调用主体源属于策略库当中配置的第三方代码集合，则根据第三方代码的访问控制策略信息判断当前操作是否准许；
步骤1.2.9，如果当前操作权限不在第三方代码的准许的访问授权集合中，则执行步骤1.2.5；
步骤1.2.10，如果当前操作权限在第三方代码的准许访问授权集合中，则根据访问控制策略信息返回授权结果信息，结束步骤1.2。
可选地，步骤1.3具体包括以下子步骤：
步骤1.3.1，hook模块接受到vpms的返回信息，如果返回信息是permission_granted，执行步骤1.3.2，否则执行步骤1.3.3；
步骤1.3.2，授权通过，则调用真正系统的敏感api；
步骤1.3.3，授权失败，返回错误，结束步骤1.3。
可选地，若当前操作属于文件访问操作，则iohook模块将被触发，获取当前需要访问的文件目录，然后交给iocheck模块结合策略库检查当前访问是否合法，若合法则调用真正的系统进行文件操作，否则禁止提权访问，包括以下子步骤：
步骤2.1.1，如果当前访问的路径是一些系统只读目录、应用自身的路径、或者sdcard目录，则允许通过访问，否则执行步骤2.1.2；
步骤2.1.2，如果当前访问的目录是别的clientapp目录、hostapp私有目录或者存放控制策略库的安全目录，则抛出异常，结束访问。
另一方面，本发明提供一种android应用多开环境中限制访问的控制系统，设andriod系统中提供虚拟化运行环境的应用为hostapp，hostapp支持andriod系统中的应用在其构建的虚拟化运行环境中运行，设在此虚拟化环境中被加载运行的应用为clientapp，包括：
敏感api访问权限控制模块，用于当clientapp运行时，若当前操作为敏感api调用操作，则结合已加载的策略信息判断所述敏感api调用操作是否合法，若合法则允许该clientapp调用真正的api，否则禁止提权调用；
文件目录的访问控制模块，用于若当前操作属于文件访问操作，则iohook模块将被触发，获取当前需要访问的文件目录，然后交给iocheck模块结合策略库检查当前访问是否合法，若合法则调用真正的系统进行文件操作，否则抛出异常，结束访问；
策略库管理模块，用于hostapp在加载clientapp的同时，解析其包含权限清单数据的文件，得到文件中列出的权限清单，作为默认的准许授权集合，再综合开发者的策略配置信息，形成最终的授权集合。
可选地，所述敏感api访问权限控制模块，用于当clientapp运行时，如果当前操作属于敏感api调用操作，apihook模块将自动被触发并获取当前调用的调用链，通过调用链获取发起此次调用的主体源信息，即修改框架中已有的hook模块；hook模块将当前的调用信息发送到远程的vpms；vpms首先得到调用发起者的信息，然后vpms将调用pcheck模块，pcheck模块结合policymanager已加载的策略信息判断当前调用是否合法，然后将结果反馈给apihook模块；apihook模块根据反馈结果进行校验，如果校验通过则允许调用真正的系统api，否则禁止提权调用。
总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有以下有益效果：
1、实现了针对第三方多开应用运行环境中的敏感api访问权限控制，由于采用步骤1.1、步骤1.2、步骤1.3，不仅能限制住clientapp使用超出自身申请的权限，而且还能限制clientapp中包含的第三方代码使用超出clientapp申请的权限。
2、实现了限制clientapp访问其不该访问的文件目录，防止被加载的恶意clientapp访问别的clientapp的私有文件，造成用户隐私信息的泄露。
3、除了默认的访问策略之外，还支持开发者配置相关的访问策略，进一步细粒度的限制运行在多开环境中的应用权限。
4、兼容原有的系统和应用。在本发明所采取的步骤中，均不涉及改变应用程序和系统的流程。
5、系统整体开销小。由于采用了步骤1.2，只在原有系统上增加了一次跨进程调用的开销，而且在权限校验过程中涉及的额外信息如敏感api与权限的映射关系可在系统初始化的时候加载，对之后的系统运行几乎没有影响。
附图说明
图1为本发明提供的android应用多开环境中限制访问的控制系统整体架构；
图2为本发明提供的android应用多开环境中限制访问的控制方法流程图；
图3为本发明提供的模块一的步骤1.1的细化流程图；
图4为本发明提供的模块一的步骤1.2的细化流程图；
图5为本发明提供的模块一的步骤1.3的细化流程图；
图6为本发明提供的模块二的步骤细化流程图；
图7为本发明提供的模块三的步骤细化流程图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
以下首先就本发明的技术术语进行解释和说明：
android：由google主导开发的基于linux内核的移动操作系统，以其开放的特性在移动操作系统市场上拥有较高的占有率。
虚拟机：指android系统中的应用程序运行时，具体指dalvik虚拟机。
android应用程序：运行在android系统中的应用程序，主要由java语言开发。
hostapp：多开应用，即能够支持其他应用在其构建的虚拟化运行环境中运行的应用，我们称其为hostapp。
clientapp：被加载运行在hostapp虚拟化环境中的android应用程序。
其中，hostapp也可称为宿主应用，clientapp也可称为运行应用。
多开应用开发框架：用来帮助开发者使用动态hook和动态加载技术实现hostapp的框架，以virtualapp开源开发框架为例，目前，virtualapp能够提供多种应用在其内部相对稳定运行，包括有java开发android应用，基于native开发的原生应用，以及一些被加固的应用。
第三方代码：应用程序开发者集成的一些由第三方开发者、公司或者其他单位开发的具有某种特定功能的库。
安全增强：针对系统中存在的一类安全问题对系统相关安全机制进行改进，以解决此类安全问题。
隐私数据：用户存储在系统中的个人数据，在移动设备中主要包括联系人信息、通话记录、地理位置信息和设备相关信息等。
应用程序编程接口(applicationprogramminginterface，api)：指一些预先定义的函数，其主要目的是让应用程序开发人员调用一组例程功能，而无须考虑其底层的源代码或理解其内部工作机制的细节。
系统包管理服务(packagemanagerservice，pms)：android系统核心服务之一，负责应用程序包的安装、卸载以及权限的授权评估，运行在系统核心进程中。
虚拟的系统包管理服务(virtualpackagemanagerservice，vpms)：是对系统真实的packagemanagerservice的虚拟化，主要完成对clientapp的授权、包信息、组件信息等资源的管理。
针对现有技术的缺陷，本发明的目的在于提供一种android应用多开环境中限制恶意提权的访问控制方法，基于已有的应用多开框架virtualapp，对其进行扩展，并开发一款安全增强型的应用多开框架sechostapp，在无需对android系统本身和应用进行修改的情况下，提出了针对多开环境中应用对敏感api的访问权限控制方法、提出了针对多开环境中应用对文件目录的访问控制方法。将访问控制的粒度细化到第三方代码级别，因为很有可能正常应用携带含有恶意提权的第三方代码，所以有必要对第三方代码实施敏感api的访问权限控制。
为实现上述目的，本发明提供了一种多开应用环境中限制恶意提权的访问控制方法，称提供虚拟化运行环境的应用为hostapp，在虚拟化环境中被加载运行的应用为clientapp。其主要包括三个模块；一是敏感api的访问权限控制模块，二是文件目录的访问控制模块，三是策略库管理模块。模块一：敏感api的访问权限控制模块实施步骤；
步骤1.1，当clientapp运行时，如果当前操作属于敏感api调用操作，apihook模块将自动被触发并获取当前调用的调用链，通过调用链获取发起此次调用的主体源信息，即修改框架中已有的hook模块；hook模块将当前的调用信息发送到远程的vpms；
步骤1.2，vpms首先得到调用发起者的信息,然后vpms将调用pcheck模块，pcheck模块结合policymanager已加载的策略信息判断当前调用是否合法等，然后将结果反馈给apihook模块；
步骤1.3，apihook模块根据反馈结果进行处理，如果校验通过则允许调用真正的系统api，否则禁止提权调用；
步骤1.1具体包括以下子步骤：
1.1.1，clientapp发起敏感api调用请求；
1.1.2，敏感api调用请求首先被hook代码拦截；
1.1.3，hook代码首先获取当前调用的敏感api名称、当前clientapp的包名以及进程pid；
1.1.4，hook模块在应用程序所在进程空间的api拦截处创建throwable对象；
1.1.5，通过throwable对象获取系统调用堆栈信息，根据系统调用堆栈信息获取本次调用的发起主体信息；
1.1.6，hook模块将当前调用源信息、调用的敏感api信息、以及当前clientapp的包名、进程pid封装到parcel对象中；
1.1.7，将此对象通过vpms的远程代理接口vpackagemanager通过进程间调用的方式发送至vpms；
步骤1.2具体包括以下子步骤：
1.2.1，vpms首先从parcel对象中读取当前调用源信息、调用的敏感api信息、以及当前clientapp的包名、进程pid；
1.2.2，根据权限与api的映射关系，得到调用当前敏感api所需申请的权限名称；
1.2.3，根据clientapp的包名，在策略库中查找相关的策略配置，包括针对clientapp的访问控制策略信息、以及clientapp中包含的第三方代码的访问控制策略信息；
1.2.4，如果当前的调用主体源是不属于策略库当中配置的第三方代码集合，则执行步骤(1.2.5)，否则执行步骤(1.2.8)；
1.2.5，根据步骤1.2.2中的到的权限名称和clientapp的包名、准许的访问授权集合，判断当前操作所涉及的权限是否在准许的访问授权集合当中；
1.2.6，如果存在准许的访问授权集合当中，则返回permission_granted；结束步骤1.2；
1.2.7，如果不存在准许的访问授权集合当中，则返permission_denied；结束步骤2；
1.2.8，如果当前调用主体源属于策略库当中配置的第三方代码集合，则根据第三方代码的访问控制策略信息判断当前操作是否准许；
1.2.9，如果当前操作权限不在第三方代码的准许的访问授权集合中，则执行步骤(1.2.5)；
1.2.10，如果当前操作权限在第三方代码的准许访问授权集合中，则根据访问控制策略信息返回授权结果信息，结束步骤2；
步骤1.3具体包括以下子步骤：
1.3.1，hook模块接受到vpms的返回信息，如果返回信息是permission_granted，执行步骤(1.3.2)，否则执行步骤(1.3.3)；
1.3.2，授权通过，则调用真正系统的敏感api；
1.3.3，授权失败，返回错误，结束步骤1.3；
模块二：文件目录的访问权限控制模块实施步骤；
步骤2.1，如果当前操作属于文件访问操作，iohook模块将被触发，获取当前需要访问的文件目录，然后交给iocheck模块结合策略库检查当前访问是否合法，如果合法才调用真正的系统调用进行文件操作。
步骤2.1具体包括以下子步骤：
2.1.1，如果当前访问的路径是一些系统只读目录、应用自身的路径、或者sdcard目录，则允许通过访问，否则执行步骤(2.1.2)；
2.1.2，如果当前访问的目录是别的应用程序目录、宿主应用私有目录
或者存放控制策略库的安全目录，则抛出异常，结束访问；
模块三：策略库的生成模块实施步骤；
步骤3.1，宿主应用在加载运行应用的同时，解析其manifest.xml文件，得到文件中列出的权限清单，作为默认的准许授权集合，再综合开发者的策略配置信息，形成最终的授权集合；
以下结合实施例和附图对本发明做进一步说明。
导致hostapp运行环境中可能的提权攻击的主要原因在于应用之间、应用与宿主应用之间共享同一个uid，然而系统底层是基于用户的访问控制，也就意味着这些应用和宿主应用共享同样的权限、目录。一旦用户在使用过程中不慎在多开环境中加载运行了含有针对多开环境进行恶意攻击的应用程序，恶意程序或者应用中包含的恶意第三方代码将可获得hostapp申请的所有权限，包括对其他重要应用文件目录的访问读写，从而造成隐私信息泄露。本发明提出一种新的安全增强方案，其目的是在兼容原有应用程序结构与原有多开应用开发框架的条件下实施针对多开环境中的提权访问控制，并细化访问控制的主体粒度，能够控制clientapp中包含的第三方代码的提权访问。同时，进一步实现控制clientapp能够访问文件目录。所有的控制策略可基于统一的策略描述语言进行动态配置，支持运行时策略更新。
图1显示了针对android应用虚拟化多开框架的安全增强方法整体架构，从图1可以看出，本发明主要的工作集中在以下三个部分：一是增加了敏感api调用权限的校验，在涉及敏感api的调用处进行hook拦截。二是增加了文件目录的访问控制，通过在已有的nativehook基础上新增文件访问检查模块。三是策略库的管理，主要的通过policymanager提供的接口进行策略库的管理。
图2显示了针对android多开环境中限制提权的访问控制方法整体流程，当用户使用开发者使用安全增强框架开发出来的hostapp的时候，首先用户需要一个加载虚拟安装的过程，将要启动的clientapp虚拟安装在hostapp给其分配的文件目录下，接下来包括具体的模块和实施步骤：
模块一：敏感api的访问权限控制模块实施步骤；
步骤1.1，当clientapp运行时，如果当前操作属于敏感api调用操作，apihook模块将自动被触发并获取当前调用的调用链，通过调用链获取发起此次调用的主体源信息，即修改框架中已有的hook模块；hook模块将当前的调用信息发送到远程的vpms；
步骤1.2，vpms首先得到调用发起者的信息,然后vpms将调用pcheck模块，pcheck模块结合policymanager已加载的策略信息判断当前调用是否合法等，然后将结果反馈给apihook模块；
步骤1.3，apihook模块根据反馈结果进行处理，如果校验通过则允许调用真正的系统api，否则禁止提权调用。
模块二：文件目录的访问权限控制模块实施步骤；
步骤2.1，如果当前操作属于文件访问操作，iohook模块将被触发，获取当前需要访问的文件目录，然后交给iocheck模块结合策略库检查当前访问是否合法，如果合法才调用真正的系统调用进行文件操作。
模块三：策略库的生成模块实施步骤；
步骤3.1，宿主应用在加载运行应用的同时，解析其manifest.xml文件，得到文件中列出的权限清单，作为默认的准许授权集合；再综合开发者的策略配置信息，形成最终的准许授权集合；
进一步地，如图3所示，所述模块一的步骤1.1包括以下子步骤：
1.1.1，应用程序发起敏感api调用请求；不失一般性，假设该api为telephonymanager.getdeviceid；
1.1.2，敏感api调用请求首先被getdeviceidhook代码拦截，也就是流程图中的apihook,系统中对所有api的具体hook类都继承apihook基类(getdeviceidhook继承apihook)，所以当敏感api被调用时首先触发的是apihook也就是基类的公共check函数；
1.1.3，apihook模块首先获取当前调用的敏感api名称apiname、当前clientapp的包名packagename、进程pid；
1.1.4，apihook模块在应用程序所在进程空间的api拦截处创建throwable对象；
1.1.5，通过throwable对象触发fillinstacktrace方法生成系统调用堆栈，再通过getstacktrace方法获取此次调用的系统异常堆栈数据，进一步获取此次调用的调用链，根据系统调用堆栈信息获取本次调用的发起主体信息即sourcepackage；
1.1.6，apihook模块将当前调用源信息sourcepackage、调用的敏感api信息apiname、以及当前clientapp的包名packagename、进程pid封装到parcel对象中；
1.1.7，apihook模块将此对象通过vpms的远程代理vpackagemanager以进程间调用的方式发送至vpms；
进一步，如图4所示，所述模块一的步骤1.2包括以下子步骤：
1.2.1，vpms首先从parcel对象中读取当前调用源信息sourcepackage、调用的敏感api信息apiname、以及当前clientapp的包名packagename、进程pid；
1.2.2，调用policymanager.getpermissionbyapi()，根据权限与api的映射关系，得到调用当前敏感api所需申请的权限名称cur_permission；
1.2.3，根据clientapp的包名，使用policymanager查找相关的策略配置，调用policymanager.getapplevelallowset(packagename)得到clientapp的访问控制授权策略集合appallows，调用policymanager.getliblevelallowset(packagename)，得到clientapp中包含的第三方代码的访问控制授权策略信息集合liballows；
1.2.4，如果当前的调用主体源sourcepackage不在策略库当中配置的第三方代码访问控制策略集合liballows中，则执行步骤(1.2.5)，否则执行步骤(1.2.8)；
1.2.5，根据步骤1.2.2中的到的权限名称和clientapp的包名、准许的访问授权集合appallows，判断当前操作所涉及的权限是否在准许的访问授权集合当中,即clientapp的当前访问不能使用
1.2.6，如果存在准许的访问授权集合当中，则返回permission_granted；结束步骤1.2；
1.2.7，如果不存在准许的访问授权集合当中，则返permission_denied；结束步骤1.2；
1.2.8，如果当前调用主体源属于策略库当中配置的第三方代码集合liballows，则根据第三方代码的访问控制策略信息判断当前操作是否准许；
1.2.9，如果当前操作权限不在第三方代码的准许的访问授权集合中liballows，则执行步骤(1.2.5)；
1.2.10，如果当前操作权限在第三方代码的准许访问授权集合中，则返回permission_granted；结束步骤1.2；
进一步，如图5所示，所述模块一的步骤1.3包括以下子步骤：
1.3.1，apihook模块接受到vpms的返回信息message，如果返回的信息是permission_granted，执行步骤(1.3.2)，否则执行步骤(1.3.3)；
1.3.2，授权通过，则调用真正系统的敏感api；
1.3.3，授权失败，返回错误，结束步骤1.3。
进一步，如图6所示，所述模块二的步骤细化流程包括以下子步骤：
2.1.1，当应用进行文件访问操作时候，iohook模块会自动触发，拦截当前要访问的目录path，交给iocheck函数检查当前访问是否合法。如果当前访问的路径path是一些系统只读目录system、dev等目录)、应用自身的路径(这里以/data/data/com.host.app/virtual/com.client_1/为例)、或者sdcard目录(/sdcard/)，则允许通过访问，否则执行步骤(2.1.2)；
2.1.2，如果当前访问的目录是别的应用程序目录(如/data/data/com.host.app/virtual/com.client_2/)、宿主应用私有目录或者存放控制策略库的安全目录，则抛出异常，结束访问。
进一步，如图7所示，所述模块三的步骤细化流程包括以下子步骤：
步骤3.1.1，宿主应用在加载运行应用的同时，解析其manifest.xml文件，得到文件中列出的权限清单，作为默认的准许授权集合；调用policymanager的远程接口policymanagerproxy将允许授权的集合通过policymanager更新到策略库中；
步骤3.1.2，policymanager再综合多开应用的开发者的策略配置信息，开发者的配置信息放置在/data/data/com.host.app/private/目录下，以xml的统一策略描述语言进行配置，不失去一般性，我们假设配置的策略为：
该配置的含义是禁止包名为com.client_1的应用访问需要android.permission.read_phone_state权限的api，policymanager根据配置形成最终的准许授权集合，最终调用policymanager的函数updatepolicy更新以当前packagename为包名的应用授权访问策略。
本发明提供的android应用多开环境中限制恶意提权的访问控制方法及系统，对已有开源的应用虚拟化多开框架进行安全增强，限制被多开的应用由于共享宿主应用的超级权限而造成的提权攻击行为。主要的安全增强模块包括：限制应用及应用中包含的第三方代码对敏感应用编程接口(api)的提权访问、文件目录的访问控制以及设计统一的访问控制策略语言支持动态配置；敏感api的访问权限控制，主要通过java层钩子(hook)技术拦截应用和系统之间所有的敏感api调用，再根据访问策略的配置最终判断是否允许调用当前敏感api。文件目录的访问控制主要通过android本身(native)的hook技术，接管应用和系统所有的文件访问操作，根据当前访问的路径判断当前应用是否访问了不该访问的文件目录。基于xml的技术标准，设计了统一的策略语言支持动态策略配置。本发明以较小的性能开销为代价对原有应用多开系统进行安全增强，相对于原有应用多开系统，访问控制粒度更加细致，可以限制应用多开境中的提权攻击，且方法使用灵活，不需对android系统和应用进行修改，具有很好的可用性。
本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。