CN104885092B - 用于操作系统的安全系统和方法 - Google Patents

Abstract

公开了一种在运行于设备上的包括基于LINUX的内核的操作系统的安全系统中使被存储在策略数据库中并且特定于在应用层中的应用的安全策略与在LINUX层中启动的相应的新进程相链接的方法。系统架构由中间件层限定，该中间件层在与内核相关联的LINUX层与包括多个应用的更高的应用层之间。

Description

用于操作系统的安全系统和方法

技术领域

本说明书涉及用于计算机操作系统的安全系统和方法，该操作系统包括但不限于Linux系统或基于Linux的系统。具体地，然而并非排他地，安全系统适于硬件设备和系统，比如移动电话、智能电话、平板计算机以及其他的便携式和台式的计算和通信设备。

背景技术

能够从加利福尼亚州山景城的谷歌公司得到的ANDROID^TM操作系统(安卓(Android))是主要针对触屏移动设备(比如智能电话和平板计算机)设计的基于Linux的操作系统。Android在其核心使用Linux内核，并且Android还提供软件开发者可以用来实现Android应用和服务的应用框架。另外地，Android在Linux内核接口与Android应用和服务之间提供本机中间件层，该Android应用和服务在更高的应用层执行，以使得能够实现用于跨不同类型的硬件设备部署相同的应用和服务的较简单的跨平台开发。

此中间件层包括共享库集合，该共享库集合提供服务(比如，数据存储、屏幕显示或多媒体)，并且该共享库集合被编译成机器语言以使服务能够快速执行。中间件库实现设备特定函数。因此，应用和应用框架自身不需要关注Android设备之间的变化。中间件层还支持Java运行时间的专业版以简化跨平台开发。具体地，中间件层提供Dalvik虚拟机(DVM)及其核心Java应用库。可以将由开发者实现的应用或服务从Java(或其他的支持语言)编译成可以由DVM运行的字节代码。

虽然中间件层简化了应用开发，但是中间件层还向总Android操作系统显著添加了更多的复杂性。这种添加的复杂性可以被所编程的应用或服务利用以执行恶意的任务(恶意软件)或执行恶意的代码(恶意代码)。

通过示例，恶意软件或恶意代码可以利用进程间通信(IPC，Inter-ProcessCommunication)或组件间通信(ICC，Inter-Component Communication)来攻击敏感应用及其数据。参照图1，每个Android应用10、12在相应的DVM 14、16中被执行。当每个应用被启动时，每个应用对应于DVM的实例。每个DVM 14、16被映射成在Linux层24中以用户模式22运行的专用进程18、20。在Android中，应用可以使用IPC机制彼此通信。然而，Android中实现IPC的标准机制是绑定(Binder)框架。Binder框架易于将函数和数据从一个进程绑定至另一个进程。Android中的Binder框架被提供为三级。在应用层42，存在使应用能够彼此通信的应用编程接口(API)26、28。作为此API的一部分的Android接口定义语言允许开发者针对Android服务定义该接口，并且AIDL剖析器生成服务客户端可以使用的Java客户端代码和开发者可以用来创建服务实现的服务存根(service stub)。在本机中间件层44处，使用C++语言实现的Binder类30经由Java本机接口(JNI，Java Native Interface)提供了便于由应用使用的用户空间，并且该Binder类30与Binder内核驱动器32进行交互，该Binder内核驱动器32是定制的Linux Android内核的一部分。Binder内核驱动器32执行进程之间的消息传递，并且提供共享存储器设施。驱动器位于特定设备/dev/binder之后，并且可以通过各种系统呼叫比如open(打开)和ioctl来使用，以实现进程能够彼此通信。

如图1所示，IPC机制可以被描述为两层。在Android层46处，当如在34所示，应用1(10)通过其AIDL API(26)发送IPC时，如在(36)所示，中间件中的binder代码30会负责将请求递送至目的地应用1(12)。在Linux层，如在(38)所示，此操作被翻译成由进程1(18)(对应于应用1)使用binder内核驱动器(/dev/binder)32来执行的系统呼叫(open和ioctl)的序列。然后，如在(40)所示，该请求被转发至进程2(20)(对应于应用2)。

在常规的Unix和Linux操作系统中，已提出了以能够跟踪进程以加强安全策略的内核模块的形式的安全系统，比如SELinux或Linux安全模块。这涉及重新编译内核图像，以注册模块并且能够最终加载该模块。另外地，当用户经由壳(shell)命令行启动新应用时，监视模块能够通过分析命令行变元(argument)将正确的安全策略与新启动的进程相链接。这样的安全系统在Android上不能有效地工作，Android使用了显著不同的启动和管理应用的方式。还期望具有不需要重新编译Linux内核的用于Android的安全系统。

在以上安全系统中，恶意应用可以通过转换成与经由壳命令行变元启动的应用不同的应用来欺骗安全系统。这意味着，安全系统认为所启动的进程是由初始壳命令行变元指定的应用而将不正确的安全策略集合与所启动的进程相关联。

短语“OS虚拟化”指的是允许多个OS实例或多个隔离的用户空间共享相同的设备硬件资源的技术。每个OS实例与其他的实例完全隔离地运行。通常，可以使用下述三种可选技术来实现虚拟化：使用二进制翻译的全虚拟化、半虚拟化或硬件支持虚拟化。

通过自动将来自客户端OS的二进制指令翻译成低级指令以实现使硬件虚拟化的效果来实现全虚拟化。虽然全虚拟化不需要在客户端OS中的修改，但是全虚拟化的主要缺点是翻译指令所需要的额外计算资源。这会成为电力资源受限的设备的问题，原因是这减少了单电池充电的操作时间。

半虚拟化指的是以下述这样的方式修改客户端OS的技术：客户端OS并不执行标准指令，而是将执行特定指令集合来与部署了该客户端OS的虚拟环境进行通信。半虚拟化提高了性能，然而代价是对客户端OS的大量修改。这意味着，尤其对于Android OS的情况，需要开发并且保持Android OS的具体图像。

硬件支持虚拟化需要CPU完全支持的特定指令集合。

以上所有三种虚拟化方法共同存在三个主要缺点。第一，三种虚拟化方法是粗粒度的，原因是这三种虚拟化方法以整个OS图像级应用虚拟化。有时，只需要将单个进程与运行的服务中的其余进程而非整个OS中的其余进程隔离。第二，三种虚拟化方法没有提供增强的安全控制。使客户端OS虚拟化并不意味着使该客户端OS更安全。将针对OS的每个实例复制与简单OS中的安全级相同的安全级。如果OS实例受到包含恶意软件的粗糙应用的危害，则OS实例内的所有应用和资源将暴露于那个粗糙应用。除非OS本身能够处理这样的威胁，否则虚拟化不会独自提供额外级保护。第三，以上虚拟化技术表现出静态行为之处是该虚拟化只关注针对不同的OS实例执行对底层硬件分区的指令。不产生任何动态决定。

在本说明书中，参照了专利说明书、其他的外部文献或其他的信息源，这通常是为了提供用于论述各个实施例的特征的语境。除非另有具体说明，否则对这种外部文献的参照不应当解释为承认：这种文献或这种信息源在任何管辖范围中是现有技术或构成本领域内公知常识的一部分。

发明内容

本文中至少一些实施例的目的是提供一种用于基于Linux的操作系统的安全系统和方法，其中，针对每个应用的安全策略可以被配置在应用层并且在更低Linux层被执行，或者本文中至少一些实施例的目的是至少向公众提供有用选择。

本文中至少一些实施例的目的是提供一种用于使安全策略与应用相链接的改进安全系统和方法，或者本文中至少一些实施例的目的是至少向公众提供有用选择。

本文中至少一些实施例的目的是提供一种用于提供在设备上操作的多个隔离的用户空间实例的可选虚拟化机制，或者本文中至少一些实施例的目的是至少向公众提供有用选择。

在第一方面，一些实施例包括用于使在设备上运行的操作系统安全的方法，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义，该方法包括：

监视由Linux层中的母进程进行的向内核的系统呼叫，以检测与应用层中的新应用或部分应用相对应的在Linux层中的新进程的启动；以及

在由母进程创建了Linux层中的新监视进程时，使该新监视进程与新启动进程相附接(attach)，该监视进程被配置成监视由新进程进行的向内核的系统呼叫，并且该监视进程被配置成基于所检测到的系统呼叫的参数来检索并且执行为新进程配置的安全策略。

在一个实施例中，系统架构还通过在Linux层与更高应用层之间的中间件层来定义。

通过示例，可以由设备的用户、操作系统本身或者已运行的应用或进程来启动新应用或部分应用。应用层中的新应用或部分应用的启动对应于Linux层中进程的开始、启动或分叉(fork)。

在一些实施例中，该方法还包括在策略数据库中为应用层中应用提供安全策略。在另一些实施例中，策略数据库存储在设备上，或者该策略数据库远程地进行存储然而能够被该设备访问。在一个实施例中，可以采用一个或更多个策略配置文件的形式来提供策略数据库。

在一些实施例中，该方法还包括在策略数据库中为应用层中应用定义并且存储安全策略。

在一些实施例中，操作系统是Android。在另一些实施例中，母进程是Zygote进程。

使监视进程与Linux层中新进程相附接可以包括：将监视进程配置为主机进程并且将相关联的新进程配置为该监视进程的目标进程。另外地，在一些实施例中，使监视进程与新进程相附接包括：请求内核执行跟踪系统呼叫，该跟踪系统呼叫被配置成拦截由目标进程执行的所有系统呼叫或至少一组系统呼叫，并且被配置成在执行这种系统呼叫之前向主机进程报告这些系统呼叫。通过示例，该跟踪系统呼叫可以是进程跟踪系统呼叫(ptrace)。在一些这种实施例中，内核被配置成既在执行由目标进程进行的系统呼叫之前和之后并且在一些实施例中在内核实际上恢复目标进程执行之前向主机进程报告该系统呼叫。

在另外的实施例中，监视进程可以被配置成从在应用层处的安全系统服务访问并且检索用于该监视进程的目标进程的安全策略，该安全系统服务已访问了策略配置文件中的用于应用层的应用的可配置安全策略。在一些这种实施例中，Linux层处的监视进程被配置成与应用层处的安全系统服务建立通信链接。通过示例，该通信链接可以是直接链接，比如，传输控制协议(TCP)链接或连接、unix套接字、共享存储器、消息、管或IPC的其他手段。

在一些实施例中，该方法还包括通过下述操作来向新进程监视器加载用于该新进程监视器的目标进程的相关安全策略：

当目标进程专用为预期的应用时监视该目标进程的专用化进程；

从专用化进程中提取应用识别数据，该专用化进程表示该目标进程正专用为该应用；以及

基于所提取的应用识别数据来检索用于该目标进程的相关安全策略。

通过示例，应用识别数据可以是应用包名称。在一种形式下，该方法包括：从在目标进程进行专用化时由该目标进程调用的系统呼叫中提取应用识别数据。在另一种形式下，该方法包括：从在专用化进程期间写入了目标进程的全应用包名称的专用化数据文件中提取应用识别数据。在其他的实施例中，可选地，可以通过本地数据存储装置或远程数据源来检索该识别数据。

基于所提取的应用识别数据来检索用于目标进程的相关安全策略可以包括：向应用层中的安全系统服务发送对安全策略的请求，该请求包括应用识别数据。

在另一实施例中，该方法包括：基于用户空间控制参数来检索用于目标进程的相关安全策略，该用户空间控制参数指示当前在设备上操作的特定用户空间实例。用户空间控制参数可以包括识别或表示从多个用户空间实例中选择的当前操作的用户空间实例的数据。在一个实施例中，用户空间实例可以对应于操作域，比如工作域或私人域。

在一些实施例中，监视进程被配置成通过下述操作来执行所检索到的用于该监视进程的目标进程的安全策略：关于所检测到的系统呼叫基于所检索到的安全策略在Linux层实现安全动作。该安全动作可以包括下述动作中的任何一种或更多种动作：允许系统呼叫进行、阻止系统呼叫进行、在系统呼叫执行之前修改系统呼叫的参数或在系统呼叫执行之后返回由系统呼叫生成的值、或者提示设备的用户选择安全动作。通过示例，监视进程可以通过由相附接的监视进程来命令并且控制该内核关于内核对所请求的系统呼叫的执行，来实现安全动作。

每个进程监视器可以被配置成基于从所检测到的系统呼叫中提取的参数来执行安全策略。针对显式系统呼叫，可以直接地基于所提取的系统呼叫参数来评价并且执行安全策略。针对隐式系统呼叫，进程监视器可以被配置成：在评价并且执行安全策略之前，从应用层中的安全系统服务检索与系统呼叫有关的其他信息。

该方法还可以包括：最初暂缓执行新进程，直到已使监视进程与新目标进程相附接为止。这种暂缓执行新进程可以包括：在目标进程的代码中注入断点以防止目标进程执行，并且随后当已建立了监视进程并且已使该监视进程与新进程相附接时，去除该断点以允许新进程专用为新应用并且执行。通过示例，断点可以是死循环或断点机器指令。

监视由母进程进行的至内核的系统呼叫可以包括：在母进程发起之前建立主监视进程，并且通过将主监视进程配置为主机进程并且将母进程配置为该主监视进程的目标进程来使主监视进程与母进程相附接。另外，使主监视进程与母进程相附接还可以包括：请求内核执行跟踪系统呼叫，该跟踪系统呼叫被配置成拦截由母进程执行的所有系统呼叫或至少系统呼叫集合并且在执行系统呼叫之前向主监视进程报告该系统呼叫。

在一些实施例中，该方法还可以包括：使新单独监视进程与由母进程创建的每个新启动进程相附接，每个独立监视进程被配置成执行与针对该新启动进程的相附接的监视进程的应用相对应的安全策略。

在第二方面，一些实施例包括用于在设备上运行(例如执行)的操作系统的安全系统，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义，该安全系统包括：

在Linux层处运行的主监视进程，该主监视进程被配置成检测通过母进程对Linux层中新进程的启动，该新进程对应于设备的用户对应用层中的新应用或部分应用的启动；

进程监视器，该进程监视器由主监视进程与由母进程创建的每个新进程相附接，并且每个进程监视器被配置成监视由进程监视器的附接的进程进行的向内核的系统呼叫；以及

在应用层处运行的安全系统服务，该安全系统服务能够操作成访问所存储的用于应用层的应用的可配置安全策略，并且该安全系统服务能够与Linux层中的每个进程监视器进行通信，该安全策略对应于进程监视器的相附接的进程，并且其中，每个进程监视器被配置成基于所检测到的系统呼叫的参数来检索并且执行针对该进程监视器的相附接的进程而配置的安全策略。

在一个实施例中，系统架构还由在Linux层与更高应用层之间的中间件层来定义。

安全系统还可以包括可访问策略数据库，该可访问策略数据库包括所存储的用于应用层中应用的可配置安全策略。策略数据库可以存储在设备上，或者该策略数据库可以远程地进行存储并且能够被该设备访问。

在一些实施例中，操作系统是Android。在一些这种实施例中，母进程是Zygote进程。

通常使主监视进程与母进程相附接。可以通过进程跟踪系统呼叫来创建该附接，其中，主监视器被配置为主机进程并且母进程被配置为目标进程。

可以通过进程跟踪系统呼叫来使每个进程监视器与该进程监视器的相应进程相附接，其中，进程监视器是主机进程并且该进程监视器的相附接的相应进程是目标进程。

每个进程监视器可以被配置成：通过从安全系统服务中检索安全策略来加载用于该进程监视器的相附接的目标进程的安全策略。每个进程监视器可以被配置成：监视该进程监视器的目标进程的专用化进程以提取应用识别数据，该应用识别数据表示该目标进程正专用为应用；以及基于所提取的应用识别数据从安全系统服务中检索用于该目标进程的相关安全策略。

在一些实施例中，进程监视器(多个进程监视器)通过Linux层与应用层之间的通信链接或机制来与安全系统服务进行通信。通过示例，通信机制可以是通过TCP链接等的客户端服务器事务。

这种实施例的第二方面可以具有关于以上第一方面的实施例所提到的任何一种或更多种特征。

在第三方面，一些实施例包括在安全系统中配置与新目标进程相附接的进程监视器的方法，该安全系统用于在设备上运行的操作系统，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义，该方法包括：

当目标进程专用为其预期的应用时监视该目标进程的专用化进程；

从表示目标进程正专用为应用或应用类型的专用化进程中提取应用识别数据；

基于所提取的应用识别数据从策略数据库中检索为该目标进程所特定的安全策略；以及

配置进程监视器以执行所检索到的安全策略。

在一个实施例中，系统架构还由在Linux层与更高应用层之间的中间件层来定义。

在实施例中，该方法还包括：基于用户空间控制参数来检索为目标进程所特定的相关安全策略，该用户空间控制参数指示当前在设备上操作的特定用户空间实例。在一些这种实施例中，用户空间控制参数是识别或表示从所述多个用户空间实例中选择的当前操作的用户空间实例的数据。在一个实施例中，用户空间实例可以对应于操作域，比如工作域或私人域。

在第四方面，一些实施例包括在安全系统中使存储在策略数据库中的安全策略与Linux层中启动的对应新进程相链接的方法，该安全策略是为应用层中的应用特定的，该安全系统用于在设备上运行的操作系统，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义，该方法包括：

当新进程专用为其预期的应用时监视该新进程的在Linux层的专用化进程；

从表示目标进程正专用为应用或应用类型的专用化进程中提取应用识别数据；以及

基于应用识别数据来创建新进程与来自策略数据库的安全策略之间的链接。

在一个实施例中，系统架构还由在Linux层与更高应用层之间的中间件层来定义。

在一种形式下，创建链接包括：从策略数据库中检索安全策略，并且将该安全策略载入与新进程相附接的进程监视器中以用于执行该安全策略。

在一种实施例中，创建链接包括：基于用户空间控制参数来检索为新进程特定的相关安全策略，该用户空间控制参数指示当前在设备上操作的特定用户空间实例。用户空间控制参数可以包括识别或表示从多个用户空间实例中选择的当前操作的用户空间实例的数据。在一个实施例中，用户空间实例可以对应于操作域，比如工作域或私人域。

在第五方面，一些实施例包括在Linux层实现安全策略的方法，针对应用层中的应用或应用类型来定义该策略，其中，该方法包括：监视对被新Linux进程用于专用为其预期的应用的代码的加载和/或识别，并且基于所加载或识别的代码将用于在Linux层实现的一个或更多个安全策略与新Linux进程相链接。

通过示例，可以针对每个应用、应用类型或应用集合来定义安全策略。

在一些实施例中，使安全策略与新Linux进程相链接包括：根据被新Linux进程用于专用为其预期的应用的代码来识别用于新Linux进程的安全策略。

在一些实施例中，应用层是Android层。

上述实施例的第三方面至第五方面可以包括关于第一方面实施例和第二方面实施例所提到的任何一种或更多种特征。

在第六方面，一些实施例包括使在设备上运行的操作系统安全的方法，该操作系统包括在Linux层中的基于Linux的内核，系统架构包括在该Linux层以上的应用层中的应用，该方法包括：

将监视实体嵌入Linux层中的与应用层中的新应用或应用组件相对应的每个新启动进程内；

配置每个新启动进程，以将该新启动进程的共享的或动态的库符号调用重定向至该进程内所嵌入的监视实体；

配置每个所嵌入的监视实体，以分析由该监视实体的相关联的进程进行的重定向符号调用并且基于与该进程相关联的安全策略来执行安全动作。

在一些实施例中，共享的或动态的库符号调用对应于或表示共享的或动态的库中的函数调用或函数呼叫，该函数调用或函数呼叫意图在内核模式下调用一个或更多个系统呼叫。

在一个实施例中，该方法包括：将由进程进行的所有符号调用重定向至该进程内所嵌入的监视实体。在另一实施例中，该方法包括：将由进程进行的预定义或预定的符号调用集合重定向至该进程内所嵌入的监视实体。

在一个实施例中，该方法还包括：基于用户空间控制参数来检索为进程特定的相关安全策略，该用户空间控制参数指示当前在设备上操作的特定用户空间实例。用户空间控制参数可以包括识别或表示从多个用户空间实例中选择的当前操作的用户空间实例的数据。在一个实施例中，用户空间实例可以对应于操作域，比如工作域或私人域。

在一些实施例中，安全动作可以包括下述动作中的任何一种或更多种动作：

●拒绝执行由共享的或动态的库中的符号表示的函数呼叫，以防止函数呼叫的执行和该函数呼叫可能使用的任何系统呼叫(多个系统呼叫)的执行。

●通过向预期的共享的或动态的库发送用于执行的由符号表示的函数呼叫来允许执行该函数呼叫，以允许调用该函数呼叫和该函数呼叫可能使用的任何系统呼叫(多个系统呼叫)，或者

●通过向预期的共享的或动态的库发送用于执行的修改的函数呼叫来修改符号调用，以允许调用内核中的修改的系统呼叫。

将监视实体嵌入每个新启动进程内可以包括：将进程监视方法或函数嵌入该进程内。

配置每个新启动进程以将共享的或动态的库符号调用重定向至所嵌入的监视实体内可以包括：针对每个新启动进程配置函数呼叫插入(FCI)机制。通过示例，该FCI机制被配置成拦截符号调用并且将该符号调用重定向至该进程内所嵌入的进程监视器。

在一种形式下，FCI机制包括：在每个新进程中配置或提供代理函数集合(代理函数库)，该代理函数集合(代理函数库)拦截符号调用并且将该符号调用重定向至每个进程内所嵌入的监视实体。在一些这种实施例中，代理函数库被配置成拦截意图用于共享的或动态的库的符号调用。

在第一形式下，针对每个进程配置FCI机制包括：配置运行时间链接器以在任何其他共享的或动态的库之前使该进程与代理函数库相链接。通过示例，该方法可以包括：配置LD_PRELOAD环境变量，以在进程被启动时命令运行时间链接器与代理函数库相链接。

在第二形式下，针对每个进程配置FCI机制包括：修改进程图像来将动态链接的符号调用重定向至该进程的代理函数库。在一些实施例中，此步骤包括：在该进程的全局偏移表(GOT)中修改符号的地址条目以表明该进程的代理函数库中的条目，并且其中，GOT是该进程的可执行并且可链接格式(ELF，Executable and Linkable Format)的一部分。通过示例，代理函数库可以采用代理偏移表(POT)的形式，并且POT中的每个条目可以被配置成表明该进程的所嵌入的监视实体。

在第三形式下，针对每个进程配置FCI机制可以包括：

配置运行时间链接器以在任何其他的共享对象库之前使任何母进程与代理函数库相链接；以及

修改由母进程启动的任何新进程的在存储器中的进程图像以将共享的或动态的库符号调用重定向至该进程的代理函数库。

通过示例，操作系统可以是Android，并且母进程是Zygote进程。

在一些实施例中，该方法还可以包括：如果进程试图加载和/或执行不受信任的本机代码，则发起系统呼叫插入(SCI)机制，该SCI机制被配置成拦截由该代码进行的至内核的系统呼叫，并且将这些系统呼叫定向至监视实体以实现安全动作。在一些这种实施例中，仅在不受信任的本机代码正执行时临时启用SCI机制，并且在不受信任的本机代码完成执行时禁用该SCI机制。监视实体可以为该进程的所嵌入的监视实体或者与该进程相关联的独立监视实体。

在一个实施例中，该方法还可以包括：如果父进程启动新子进程来执行不受信任的本机代码，则发起SCI机制。在一些这种实施例中，该方法可以包括：采用进程跟踪系统呼叫的形式来发起SCI机制，以使父进程(主机进程)与新子进程(目标进程)相附接，使得由新子进程调用的任何系统呼叫被拦截并且被重定向至父进程的所嵌入的进程监视器以实现安全动作。

在另一实施例中，该方法还可以包括：如果进程试图通过动态地加载来自共享库的新符号来执行不受信任的本机代码，则发起SCI机制。

在第七方面，一些实施例包括使在设备上运行的操作系统安全的方法，该操作系统包括在Linux层中的基于Linux的内核，系统架构包括在该Linux层以上的应用层中的应用，该方法包括：

拦截由进程进行的意图调用内核中的系统呼叫的共享的或动态的库符号调用；以及

基于为应用而配置的安全策略，针对所拦截的符号调用来发起安全动作，所述应用与呼叫所拦截的符号调用的进程相对应。

在第八方面，一些实施例包括用于在设备上运行的操作系统的安全系统，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义，该安全系统包括：

在Linux层中的每个启动进程内的嵌入监视实体，每个启动进程对应于应用层中的应用；

与每个进程相关联的拦截器，该拦截器被配置成拦截由该拦截器的相关联的进程进行的共享的或动态的库符号调用中的至少一些库符号调用，并且被配置成将这些库符号调用重定向至发起符号调用的进程内所嵌入的监视实体，以及

其中，所嵌入的监视实体被配置成分析所拦截的由该监视实体的相关联的进程进行的符号调用，并且被配置成基于与该进程相关联的安全策略来执行安全动作。

在一个实施例中，系统架构还由在Linux层与更高应用层之间的中间件层来定义。

第八方面的各种实施例还可以包括相对于第四方面至第七方面的实施例所提到的特征中的任何一种或更多种特征。

在第九方面，一些实施例包括用于使在设备上运行的操作系统安全的方法，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义，该方法包括：

创建对由母进程调用的系统呼叫和/或库函数呼叫进行监视的监视实体，以检测将与应用层中新应用相对应的新进程的创建；以及

当母进程创建新启动进程时创建对该新启动进程进行监视的新监视实体，该新监视实体被配置成检测由新进程进行的系统呼叫和/或库函数呼叫，并且被配置成基于所检测到的系统呼叫和/或库函数呼叫的参数来检索并且执行为新进程配置的安全策略。

在一个实施例中，系统架构还由在Linux层与更高应用层之间的中间件层来定义。

在一种形式下，监视实体被定义为Linux进程。例如，监视实体可以是与该监视实体正监视的目标进程相链接或附接的独立监视进程。在另一种形式下，监视实体可以是正在被监视的目标进程内所嵌入的进程监视方法或函数。

应用可以是应用程序或应用组件，比如但不限于活动(Activities)、服务、内容提供者或广播接收器。

在一个实施例中，该方法还可以包括：基于用户空间控制参数来检索为新进程特定的相关安全策略，该用户空间控制参数指示当前在设备上操作的特定用户空间实例。在一些这种实施例中，用户空间控制参数是识别或表示从多个用户空间实例中选择的当前操作的用户空间实例的数据。在一个实施例中，用户空间实例可以对应于操作域，比如工作域或私人域。

在第十方面，一些实施例包括用于使在设备上运行的操作系统安全的方法，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义，该方法包括：

创建对由母进程调用的系统呼叫进行直接地或间接地监视的监视实体，以检测将与应用层中新应用相对应的新进程的创建；以及

当母进程创建新启动进程时创建对该新启动进程进行监视的新监视实体，该新监视实体被配置成直接地或间接地检测由新进程进行的系统呼叫调用，并且被配置成基于所检测到的系统呼叫调用的参数来检索并且执行为新进程配置的安全策略。

在一个实施例中，系统架构还由在Linux层与更高应用层之间的中间件层来定义。

在一种形式下，监视实体通过拦截至内核的系统呼叫调用来直接地监视或检测系统呼叫调用。在另一种形式下，监视实体通过拦截共享的或动态的库符号调用来间接地监视或检测系统呼叫调用，该库符号调用意图对至内核的一个或更多个系统呼叫进行调用。

在一个实施例中，该方法还包括：基于用户空间控制参数来检索为新进程特定的相关安全策略，该用户空间控制参数指示当前在设备上操作的特定用户空间实例。在一些这种实施例中，用户空间控制参数是识别或表示从多个用户空间实例中选择的当前操作的用户空间实例的数据。在一个实施例中，用户空间实例可以对应于操作域，比如工作域或私人域。

在第十一方面，一些实施例包括使在设备上运行的操作系统安全的方法，该操作系统包括在Linux层中的基于Linux的内核，系统架构包括在该Linux层以上的应用层中的应用，该方法包括：

使用第一监视机制来检测由进程进行的共享的或动态的库符号调用，并且基于与调用该符号调用的相应进程相关联的安全策略，针对所检测到的符号调用来发起安全动作；

检测试图执行预定义的高风险动作集合中的一个高风险动作的高风险进程；以及

发起第二监视机制来监视由所检测到的高风险进程所调用的系统呼叫。

在一些实施例中，该方法包括临时发起或启用第二监视机制。具体地，根据一些实施例的方法包括：仅在高风险进程正在执行时发起或启用第二监视机制。在一个示例中，该方法包括：一旦高风险进程完成执行，禁用第二监视机制。在另一示例中，该方法包括：一旦危险符号或不受信任的符号已卸载时，则禁用第二监视机制。在一种形式下，当高风险进程没有加载不受信任的符号时使用例如dlclose函数呼叫来停用第二监视机制。

在一种形式下，第一监视机制在每个进程中是FCI机制，该FCI机制被配置成拦截可能意图调用内核中的一个或更多个系统呼叫的共享的和动态的库符号调用，并且被配置成将该库符号调用重定向至与该进程相关联的监视实体，该监视实体响应于每个所拦截的符号调用来发起安全动作。

在一种形式下，第二监视机制是针对每个检测到的高风险进程而配置的SCI机制。在一些实施例中，每个SCI机制被配置成拦截由高风险进程进行的至内核的系统呼叫，并且被配置成将该系统呼叫重定向至与该进程相关联的监视实体，该监视实体响应于每个所拦截的系统呼叫来发起安全动作。

通过示例，高风险动作可以包括下述动作中的任何一种或更多种动作：

●检测试图加载和/或执行不受信任的本机代码的进程，和/或

●检测试图执行或调用代码的进程，该代码可能会造成该进程或子进程绕过第一监视机制调用系统呼叫，和/或

●检测调用ldopen函数呼叫来加载共享对象(例如，写入本机代码中)的进程。

在一种形式中，该方法可以包括：如果父进程启动新子进程来执行不受信任的本机代码，则发起SCI机制。在一些这种实施例中，该方法包括：采用进程跟踪系统呼叫的形式来发起SCI机制，以使父进程(主机进程)与新子进程(目标进程)相附接，使得由新子进程调用的任何系统呼叫被拦截并且被重定向至与父进程相关联的监视实体以实现安全动作。

在第十二方面，一些实施例包括使在设备上运行的操作系统安全的方法，该操作系统包括在Linux层中的基于Linux的内核，系统架构包括在该Linux层以上的应用层中应用，该方法包括：

发起被配置成对由进程进行的至少一些共享的或动态的库符号调用进行检测的一次监视机制，并且基于与调用所检测到的符号调用的进程相关联的安全策略，针对所检测到的符号调用来执行安全动作；

检测试图执行预定义的高风险动作集合中的一个高风险动作的高风险进程，并且切换成二次监视机制来检测由所检测到的高风险进程所调用的系统呼叫；以及

基于与调用所检测到的系统呼叫的所检测到的高风险进程相关联的安全策略，针对每个所检测到的系统呼叫来执行安全动作。

在一种形式下，一次监视机制是FCI机制，该FCI机制被配置成检测可能意图对至内核的一个或更多个系统呼叫进行调用的共享的和动态的库符号调用，并且二次监视机制是SCI机制，该SCI机制被配置成检测至内核的系统呼叫。

在第十三方面，一些实施例包括使一个或更多个应用特有安全策略与在设备的操作系统中的新进程相链接的方法，该设备具有：操作系统，该操作系统能够操作成运行进程；以及中间件，该中间件能够操作成通过从现有进程或母进程分裂或分叉出新进程来使该操作系统启动新进程，并且能够操作成使用为应用特定的代码来使新进程专用为运行应用，所述方法包括：

检测新进程；

在检测到新进程之后监视预定义事件或预定义识别阈值；以及

在检测到预定义事件或达到预定义识别阈值时使一个或更多个安全策略与新进程相链接。

在一些实施例中，检测新进程包括：检测新进程的启动，并且在检测到新进程之后监视预定义事件或预定义识别阈值。在一种形式下，新进程的启动包括：从父进程或母进程分叉出新进程。

在实施例中，操作系统包括在Linux层中的基于Linux的内核，并且其中系统架构包括在该Linux层以上的应用层中的应用。

在一种形式下，预定义事件是对所述新进程的分叉完成。在另一种形式下，预定义事件是使用新进程的应用特定代码对新进程的专用化。在另一种形式下，预定义事件是开始执行应用特定代码。

在一种形式下，预定义识别阈值对应于采集或接收到足够的下述数据或证据：该数据或证据指示或识别出Linux层中启动的新进程对应于用户意图启动的在应用层中的应用。

在一种形式下，使一个或更多个安全策略与新进程相链接包括：提取应用识别数据，该应用识别数据表示该进程将专用为、正专用为、或已专用为的应用或应用类型；以及基于应用识别数据从策略数据库中检索一个或更多个安全策略。

在另一种形式下，使一个或更多个安全策略与新进程相链接包括：在新进程已专用化之后监视新进程的执行；基于新进程的执行来表征应用的类型；以及基于该表征从策略数据库中检索一个或更多个安全策略。

在一些实施例中，使一个或更多个安全策略与新进程相链接包括：使用一个或更多个安全策略来配置与进程相关联的监视实体，该监视实体被配置成监视该进程的执行并且执行该一个或更多个安全策略。

在一种形式下，应用识别数据是应用名称或程序名称。

在一种形式下，从文件中检索应用名称。在另一种形式下，从新进程的存储器中检索应用名称。在另一种形式下，通过IPC通道将应用名称从外部进程推送至该进程。在另一种形式下，通过IPC通道从外部进程请求或拉出应用名称。

在一些配置中，监视器可以被配置成通过下述操作使所定义的策略与进程相链接或相关联：监视对被该进程用于专用为其预期的应用的代码进行的加载和/或识别，并且基于所加载或识别的代码来使一个或更多个策略文件与该进程相链接。在这样一种配置中，监视器被配置成：在进程已被开始之后，使所定义的策略与进程相链接或相关联。在另一个这种配置中，监视器被配置成：根据用于使进程专用为给定的应用或应用类型的数据或代码，使所定义的策略与进程相链接或相关联。

在一些配置中，监视器可以被配置成通过下述操作来使所定义的策略与进程相链接或相关联：当进程专用为其预期的应用时监视该进程的专用化；从专用化进程中提取应用识别数据，该专用化进程表示进程正专用为应用；以及基于所提取的应用识别数据使一个或更多个策略文件与进程相链接。

在一些配置中，监视器可以被配置成通过下述操作使所定义的策略与进程相链接或相关联：检测进程的启动；在检测到进程的启动之后，监视预定义事件或预定义识别阈值；以及一旦检测到预定义事件或达到预定义识别阈值，则使一个或更多个策略文件与进程相链接。

在一些配置中，监视器可以包括：监视实体，该监视实体直接地或间接地监视由母进程调用的系统呼叫，以检测对将与新应用相对应的新进程的创建，以及其中，该监视器被配置成：一旦母进程创建了新启动进程，则创建新监视实体，以监视该新启动进程，该新监视实体被配置成直接地或间接地检测由新进程进行的系统呼叫调用，并且该新监视实体被配置成基于所检测到的系统呼叫调用的参数来执行与新进程相链接或相关联的策略。在一个这种配置中，监视实体可以通过拦截至内核的系统呼叫调用来直接地监视或检测系统呼叫调用。在另一个这种配置中，监视实体可以通过拦截共享的或动态的库符号调用来间接地监视或检测系统呼叫调用，该共享的或动态的库符号调用意图对至内核的一个或更多个系统呼叫进行调用。

在一种形式下，监视器可以是存储在设备上的代码，并且能够在代码被设备执行时进行操作。在另一种形式下，监视器可以是设备的硬件组件。

在第十四方面，一些实施例包括使一个或更多个应用特定安全策略与操作系统中启动的新进程相链接的方法：

包括：

检测新进程的启动；以及

至少将一个或更多个安全策略与新进程的链接延迟至该新进程使用其应用特有代码开始进行专用化以用于执行为止。

在一些实施例中，该方法包括：当新进程已完成专用化时，使一个或更多个安全策略与新进程相链接。

在第十五方面，一些实施例包括一种设备，该设备包括运行进程的操作系统和能够操作成启动应用的中间件层，其中，使用操作系统中的一个或更多个进程来运行由中间件层启动的应用，该操作系统具有用户层和内核，其中，进程在操作系统的用户层中运行并且通过内核与在用户层中运行的其他进程进行交互，该交互响应于由进程进行的至内核的呼叫，该设备还包括：

一个或更多个策略文件，该一个或更多个策略文件定义用于使进程与设备的内核交互的策略；以及

监视器，该监视器被配置成监视进程与内核的交互以使所定义的策略与进程相链接或相关联，并且被配置成读取在与进程相链接或相关联的一个或更多个策略文件中定义的代码。

在一些配置中，中间件层能够操作成使进程从现有进程或母进程分裂或分叉，并且能够操作成使该进程使用应用特定代码来专用为运行该应用。

监视代码还能够操作成执行在与进程相链接或相关联的一个或更多个策略文件中定义的策略。

操作系统可以是Linux或基于Linux。

在一些配置中，监视器可以被配置成通过下述操作使所定义的策略与进程相链接或相关联：当进程专用为其预期的应用时监视该进程的专用化；从专用化进程中提取应用识别数据，专用化进程表示该进程正专用为应用；以及基于所提取的应用识别数据使一个或更多个策略文件与进程相链接。

在一些配置中，监视器可以被配置成通过下述操作使所定义的策略与进程相链接或相关联：检测进程的启动；在检测到进程的启动之后，监视预定义事件或预定义识别阈值；以及在检测到预定义事件或达到预定义识别阈值时使一个或更多个策略文件与进程相链接。

在一些配置中，监视器还可以被配置成执行在与进程相链接或相关联的一个或更多个策略文件中定义的一个或更多个策略。

监视代码可以被配置成通过监视共享的或动态的库符号调用和/或系统呼叫来监视进程与内核的交互，并且一个或更多个策略文件可以定义响应于给定的符号调用或系统呼叫的动作，其中该给定的符号调用或系统呼叫由与一个或更多个策略文件相链接的进程来进行。该动作可以包括下述动作中的任何一种或更多种动作：阻止符号调用或系统呼叫、将符号调用重定向至可替换的库地址、将符号调用或系统呼叫记入日志、终止进程和暂停符号调用或系统呼叫以允许通过操作员(opertor)对符号调用或系统呼叫进行授权。

在一些实施例中，监视器可以被配置成通过下述操作使所定义的策略与进程相链接或相关联：监视对被该进程用于专用为其预期的应用的代码进行的加载和/或识别，并且基于所加载或识别的代码来使一个或更多个策略文件与该进程相链接。

监视代码能够在被执行时操作成：在进程已开始之后，使所定义的策略与进程相链接或相关联。监视代码能够在被执行时操作成：根据用于使进程专用于给定的应用或应用类型的数据或代码，使所定义的策略与进程相链接或相关联。

监视代码能够在被执行时操作成：运行进程内的库函数以读取由与进程相链接的一个或更多个策略定义所定义的代码。该代码能够在被执行时操作成：根据与进程相链接的一个或更多个策略定义，使能够操作成监视给定应用的监视进程开始。监视代码能够在被执行时操作成：组合运行或者在进程内的库函数之间进行切换，并且使能够操作成监视该进程的监视进程开始。

在一些实施例中，监视代码将根据正使用给定进程来运行的应用而使一个或更多个策略定义与给定进程相链接，使得为应用或应用类型特定的策略被应用于该进程。

在一些配置中，监视器可以包括：监视实体，该监视实体直接地或间接地监视由母进程调用的系统呼叫，以检测对将与新应用相对应的新进程的创建，以及其中，该监视器被配置成：一旦母进程创建新启动进程，则创建新监视实体来监视该新启动进程，该新监视实体被配置成直接地或间接地检测由新进程进行的系统呼叫调用，并且该新监视实体被配置成基于所检测到的系统呼叫调用的参数来执行与新进程相链接或相关联的策略。在一种形式下，监视实体可以通过拦截至内核的系统呼叫调用来直接地监视或检测系统呼叫调用。在另一种形式下，监视实体可以通过拦截共享的或动态的库符号调用来间接地监视或检测系统呼叫调用，该共享的或动态的库符号调用意图对至内核的一个或更多个系统呼叫进行调用。

在一种形式下，监视器是存储在设备上的代码，并且能够在代码被设备执行时进行操作。在另一种形式下，监视器是设备的硬件组件。

在第十六方面，一些实施例包括使设备上的操作系统虚拟化以提供能够在该设备上操作的多个隔离的用户空间实例的方法，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义，该方法包括：

拦截由进程进行的系统呼叫和/或库函数呼叫，每个进程对应于应用层中的应用；以及

至少基于用户空间控制参数和与进程相关联的安全策略，针对所拦截的系统呼叫和/或库函数呼叫来发起安全动作，该用户空间控制参数指示当前在该设备上操作的特定用户空间实例。

在一个实施例中，系统架构还由在Linux层与更高应用层之间的中间件层来定义。

在一些实施例中，用户空间控制参数是识别或表示从多个用户空间实例中选择的当前操作的用户空间实例的数据。在一个这种实施例中，用户空间实例可以对应于操作域，比如工作域或私人域。

安全策略可以是为应用特定的或者可以是与所有应用或应用集合相关的全局策略。在一些实施例中，每个安全策略是为用户空间特定的，使得该安全策略仅应用于在具体用户空间实例中运行的应用或应用集合。

在一些实施例中，该方法包括：提供策略数据库，该策略数据库包括多个安全策略集合，每个安全策略集合对应于用户空间实例中的至少一个用户空间实例。在一些实施例中，每个用户空间实例可以包括不同的安全策略集合，该不同的安全策略集合应用于在应用的用户空间实例在设备上的操作期间运行的应用。

在实施例中，该方法还可以包括：至少基于用户空间控制参数从策略数据库中选择安全策略或者使该安全策略与进程相链接。在另一实施例中，该方法还包括：基于用户空间控制参数和应用识别数据从策略数据库中选择安全策略或者使该安全策略与进程相链接，该应用识别数据指示应用对应于调用系统呼叫的进程。

在一种形式下，拦截系统呼叫调用包括：直接地拦截至内核的系统呼叫调用。在另一种形式下，拦截函数呼叫包括：拦截意图对至内核的一个或更多个系统呼叫进行调用的共享的或动态的库符号调用

在实施例中，直接地或间接地拦截系统呼叫调用包括：实现SCI机制和/或FCI机制。

安全动作可以包括下述动作中的任何一种或更多种动作：允许系统呼叫进行、阻止系统呼叫进行、修改系统呼叫在执行之前的参数或由系统呼叫在执行之后生成的返回值、或者终止进程。

在第十七方面，一些实施例包括用于使在设备上运行的操作系统虚拟化以提供能够在该设备上操作的多个隔离的用户空间实例的虚拟化系统，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义，该虚拟化系统包括：

与Linux层中每个启动进程相关联的监视实体，每个启动进程对应于应用层中的应用；

与每个进程相关联的拦截器，该拦截器被配置成拦截系统呼叫和/或库函数呼叫，并且被配置成将系统呼叫和/或库函数呼叫重定向至与发起系统呼叫和/或库函数呼叫的进程相关联的监视实体，以及

其中，监视实体被配置成分析所拦截的由该监视实体的相关联的进程进行的系统呼叫和/或库函数呼叫，并且被配置成至少基于用户空间控制参数和与该进程相关联的安全策略来执行安全动作，该用户空间控制参数指示当前在设备上操作的特定用户空间实例。

在一个实施例中，系统架构还由在Linux层与更高应用层之间的中间件层来定义。

如上所述的第十六方面和第十七方面可以包括相对于前述方面的实施例所提到的特征中的任何一种或更多种特征。

一些实施例的功能可以由所接收的功能代码(比如，网页代码、网页应用代码或其他的应用代码)来定义，所接收的功能代码将在经由内核访问设备资源的进程的层处被监视，该进程执行所接收的代码的功能。

一些实施例使用用于使进程专用化以将针对功能代码的策略与执行以该代码定义的功能的进程相关联的数据或代码，使得可以针对进程执行对所接收的代码的监视。

在第十八方面，一些实施例包括一种设备，该设备包括一个或更多个资源，该一个或更多个资源包括处理器并且用由该设备接收的功能代码定义的可配置功能，该设备还包括操作系统，该操作系统包括用户层和内核，该用户层能够操作成运行进程，并且该内核能够操作成给该进程提供使用该设备的一个或更多个资源的接口，其中，该设备存储启动器代码，该启动器代码能够操作成将所接收的功能代码作为新进程启动并且能够操作成使新进程根据该功能代码进行专用化，由此，使该新进程，经由由内核提供的接口，使用设备的资源，执行通过该功能代码针对设备定义的功能，其中，所述设备还存储策略代码，该策略代码定义用于所接收的每个功能代码或每个功能代码类型的策略，并且其中，设备包括监视代码，该监视代码能够操作成使策略代码的实例与进程相关联并且能够操作成根据所关联的策略代码来监视进程。

在一个实施例中，该启动器代码能够操作成通过下述操作来将所接收的功能代码作为新进程启动：使该新进程从另一进程分裂或分叉，并且使该新进程呼叫功能代码以通过该功能代码来专用为功能。

在一个实施例中，根据对功能代码或该功能代码符合的类型的识别来关联策略代码，由此，能够使用为所分裂出的进程已专用于的功能代码或代码类型特定的策略来监视执行给定的功能的进程。

在一个实施例中，功能代码可以定义一个或更多个应用，并且启动器代码定义中间件层，该中间件层能够操作成启动该一个或更多个应用，其中，使用在操作系统的用户层中的一个或更多个进程来运行由中间件层启动的应用，所述一个或更多个进程通过内核与在用户层中运行的其他进程进行交互，所述交互响应于由进程进行的至内核的呼叫，策略代码定义一个或更多个策略文件，该一个或更多个策略文件定义用于进程与设备的内核进行交互的策略，并且其中，监视代码被配置成通过监视每个进程与内核进行的使所定义的策略链接至或相关联于该进程的交互来使策略代码与该进程相关联，并且监视代码还被配置成读取在与进程相链接或相关联的一个或更多个策略文件中定义的代码。

在一个配置中，中间件层能够操作成使进程从现有进程或母进程分裂或分叉，并且能够操作成使进程使用为应用特定的功能代码来专用于运行该应用。

在一个配置中，监视代码可以被配置成通过下述操作使所定义的策略与进程相链接或相关联：监视对被该进程用于专用为其预期的应用的功能代码的加载和/或识别，并且基于所加载或识别的功能代码或对功能代码的呼叫来将一个或更多个策略文件与该进程相链接。在一种形式下，监视代码可以被配置成：在进程已开始之后，使所定义的策略与进程相链接或相关联。在另一种形式下，监视代码可以被配置成：根据用来使进程专用为给定的应用或应用类型的数据或代码，使所定义的策略与进程相链接或相关联。

在一个配置中，监视代码可以被配置成通过下述操作来使所定义的策略与进程相链接或相关联：当进程专用为其预期的应用时监视该进程的专用化；从表示进程正专用为应用的专用化进程中提取应用识别数据；以及基于所提取的应用识别数据使一个或更多个策略文件与进程相链接。

在一个配置中，监视代码可以被配置成通过下述操作使所定义的策略与进程相链接或相关联：检测进程的启动；在检测到进程的启动之后，监视预定义事件或预定义识别阈值；以及在检测到预定义事件或达到预定义识别阈值时使一个或更多个策略文件与进程相链接。

在一个配置中，监视代码还可以被配置成执行在与进程相链接或相关联的一个或更多个策略文件中定义的一个或更多个策略。

在一个配置中，监视代码可以被配置成通过监视共享的或动态的库符号调用和/或系统呼叫来监视进程与内核的交互，并且一个或更多个策略文件定义响应于给定的符号调用或系统呼叫的动作，其中该给定的符号调用或系统呼叫由与一个或更多个策略文件相链接的进程来进行。在一种形式下，该动作可以包括下述动作中的任何一种或更多种动作：阻止符号调用或系统呼叫、将符号调用重定向至可替换的库地址、将符号调用或系统呼叫记入日志、终止进程和/或暂停符号调用或系统呼叫以允许通过操作员对符号调用或系统呼叫进行授权。

在一个配置中，监视代码可以被配置成：拦截由进程进行的共享的或动态的库符号调用和/或系统呼叫，并且至少基于用户空间控制参数和与进程相关联的一个或更多个策略文件执行动作，从而使操作系统虚拟化以提供能够在设备上操作的多个隔离的用户空间实例，该用户空间控制参数指示当前在设备上操作的特定用户空间实例。

在一个配置中，监视代码可以包括：监视实体，该监视实体直接地或间接地监视由母进程调用的系统呼叫，以检测对将与新应用相对应的新进程的创建，以及其中，该监视代码被配置成：一旦母进程创建新启动进程就创建新监视实体以监视该新启动进程，该新监视实体被配置成直接地或间接地检测由新进程进行的系统呼叫调用，并且该新监视实体被配置成基于所检测到的系统呼叫调用的参数来执行与新进程相链接或相关联的策略。在一种形式下，监视实体通过拦截至内核的系统呼叫调用来直接地监视或检测该系统呼叫调用。在另一种形式下，监视实体通过拦截共享的或动态的库符号调用来间接地监视或检测系统呼叫调用，该共享的或动态的库符号调用意图对至内核的一个或更多个系统呼叫进行调用。

在一个配置中，功能代码可以定义浏览器的渲染器，该渲染器被配置成渲染下载的网页。

在一个配置中，设备可以包括定义下述动作的策略代码：该动作用于通过执行与策略代码相关联的功能代码在访问之前或之后来操纵存储在设备上的数字资产。

监视代码能够操作成根据策略采取安全动作。安全动作可以包括：将由进程进行的呼叫记入日志以及使该日志条目与关联于进程的功能代码或功能代码类型相关联。启动器代码可以定义中间件层，比如Android。启动器代码可以定义浏览器，比如Chrome或Chrome OS。

监视代码能够操作成：根据用于对要被用于使进程专用化的功能代码进行识别的代码或数据，使功能代码或功能代码类型与进程相关联。

在一些实施例中，监视代码可以包括和/或指共同执行一个或更多个功能的代码或多个代码实例，该一个或更多个功能比如但不限于：使策略与进程相关联、监视新进程的启动、根据相关联的策略来监视进程、以进程内所嵌入的监视实体或者与进程相附接的独立监视实体的形式进行实现和/或其他的监视功能，比如启动并且配置监视实体。

在第十九方面，一些实施例包括使在系统上执行的应用的操作安全的方法，该系统包括linux层和中间件层，该中间件层能够操作成通过下述操作来启动应用：使linux层中的进程从其他的进程或者从母进程分裂，并且使linux层中的进程使用为该应用特定的代码进行专用化，该方法包括：

监视母进程或现有进程以检测分裂进程；

监视分裂进程执行以便于识别哪个进程进行了专用化；以及

监视由经专用化的进程进行的函数呼叫以确定相对于该函数呼叫执行的安全动作。

在一些配置中，安全动作可以包括下述动作中的任何动作：

拒绝执行所呼叫的函数，并且将进程重定向至可以在独立库中提供的不同于原始函数的另一函数；

拒绝该函数，将进程重定向至另一函数(其可以包含在独立库中)，该另一函数执行安全检查，净化参数，并且然后呼叫原始函数；或者

执行安全检查，并且对由原始函数返回的参数执行净化。

在第二十方面，一些实施例包括计算机可读介质，该计算机可读介质上存储有计算机可读指令，该计算机可读指令在处理设备上被执行时使该处理设备执行在前述方面的实施例中限定的方法中的任何一种或更多种方法。

在第二十一方面，一些实施例包括具有处理器的系统或设备，该处理器被配置成或被编程为实现或执行在前述方面的实施例中限定的方法中的任何一种或更多种方法。

定义

如在本说明书和权利要求中使用的短语“专用化处理”或术语“专用化”，除非上下文另有说明，否则意思是指下述处理：通过该处理，例如在基于Linux的操作系统的Linux层中的新创建进程识别应用层中的与该新创建进程相关的对应应用，并且然后该新创建进程检索并且加载用于该应用的应用特用代码以用于执行，或者意指其他的基于Unix或Linux的操作系统—包括Android、iOS、Chromium和Chromium OS—中的类似这种进程。

如在本说明书和权利要求中使用的术语“相附接”或“附接”，除非上下文另有说明，否则意思是指创建Linux层中的两个进程之间的关系，由此，一个进程被配置成监视并且控制在父-子或主机-目标关系中的另一个进程，并且通过示例，该一个进程包括通过进程跟踪系统呼叫例如ptrace或者任何其他的机制的附接，该其他机制在进程之间创建使一个进程能够控制另一个进程的一个或更多个方面或功能的链接或附接。

如在本说明书和权利要求中使用的术语“Linux”，除非上下文另有说明，否则意思是指使用Linux、Unix或类似Unix的内核的任何基于Linux的操作系统。

如在本说明书和权利要求中使用的短语“Linux层”，除非上下文另有说明，否则意思是指操作系统架构中的用于描述在用户模式下进程的操作的层(用户层)和用于描述在内核模式下该进程与内核的交互的层(内核层)。

如本说明书和权利要求中使用的短语“中间件层”，除非上下文另有说明，否则意思是指操作系统架构中的用于描述在Linux层与应用层中应用软件之间操作的软件的层。

如本说明书和权利要求中使用的短语“应用层”，除非上下文另有说明，否则意思是指操作系统架构中的用于描述用户应用软件和服务的操作的层。

如本说明书和权利要求中使用的短语“母进程”，除非上下文另有说明，否则通常意思是指在操作系统启动之后运行的进程，该进程经由与内核的交互来控制Linux层处的所有新子进程的启动或发起，并且例如在Android的环境中，该进程等同于Zygote进程，该Zygote进程通过分叉出自身的新复制品或图像来发起新进程，并且例如在Chromium或Chromium OS的环境中，该进程等同于在浏览器上运行的主进程，该主进程通过分叉或分裂出自身的复制品或图像来发起新进程，并且该进程还可以称为“父进程”。

如本说明书和权利要求中使用的术语“分叉”、“分叉出”、“被分叉”，除非上下文另有说明，否则意思是指新进程的创建或分裂，并且其中，通常在基于Linux的OS中，新进程通过母进程来创建或分裂出并且作为母进程的复制品或图像开始，然而该术语意思是指通过其来发起或创建新进程的任何其他的机制。

如本说明书和权利要求中使用的术语“监视”，在主机-目标进程关系的环境中意思是指主机拦截、控制、修改和/或跟踪由目标进程向内核进行的系统呼叫，并且该术语“监视”还可以包括或者技术上称为“插入”和/或“交叉(interleave)”。

如本说明书和权利要求中使用的短语“系统呼叫插入(SCI)”和“SCI机制”或“SCI配置”，除非上下文另有说明，否则意思是指通过下述操作拦截由进程发起的系统呼叫的方法：直接地检测或拦截在Linux层的内核模式下进行或调用的系统呼叫，该系统呼叫通过示例包括但不限于共享对象库与内核中系统呼叫网关之间的交互、或者根据本机代码而不使用共享对象库向内核中系统呼叫网关进行的直接系统呼叫，并且其中，SCI机制可以通过使用例如ptrace或任何其他适合的拦截机制或系统来实现。

如本说明书和权利要求中使用的短语“系统呼叫网关”，除非上下文另有说明，否则意思是指将执行系统呼叫或执行了系统呼叫的进入点或内核中进入点。

如本说明书和权利要求中使用的短语“函数呼叫插入(FCI)”或“FCI机制”或“FCI配置”，除非上下文另有说明，否则意思是指检测或拦截由进程发起的共享的或动态的库符号调用的方法，并且其中，符号调用表示在Linux层的用户模式下从进程向共享对象库的函数调用或函数呼叫，并且其中，这组监视的符号调用是可能意图在Linux层的内核模式下调用一个或更多个系统呼叫的符号调用。

如本说明书和权利要求中使用的短语“函数呼叫”、“符号调用”、“共享的或动态的库符号调用”、或“共享对象库函数呼叫”，除非上下文另有说明，否则意思是指由进程向共享的或动态的库进行的函数调用，该函数调用可能意图在内核模式下调用一个或更多个系统呼叫。

如本说明书和权利要求中使用的术语“符号”，除非上下文另有说明，否则意思是指共享的或动态的库的表中的条目，该条目对应于或表示函数。

如本说明书和权利要求中使用的短语“策略数据库”，除非上下文另有说明，否则意思是指本地存储在设备上或能够远程访问的任何电子源或源的组合，该任何电子源或源的组合包含表示为设备上运行的应用而配置或定义的一个或更多个安全策略的数据，并且该“策略数据库”可以形式为或包括：包括定义一个或更多个安全策略的数据的策略配置文件、各自包括定义一个或更多个安全策略的数据的一组策略配置文件、或者可访问电子安全策略的任何电子源或形式。

如本文中所使用的术语“和/或”意思是指“和”、“或”或者这二者。

如本文中使用的伴随名词的“(多个)”意思是指该名词的复数形式和/或单数形式。

在前文，各种实施例包括并且还想到了下面仅给出了其示例的构造。

在以下描述中，给出具体细节以提供对实施例的透彻理解。然而，本领域内普通技术人员将理解的是，即使没有这些具体细节仍可以实践实施例。例如，为了不使实施例在不必要的细节中变得难以理解，在框图中可以示出软件模块、函数、电路等。换句话说，为了不使实施例难以理解可以不详细示出公知的模块、结构和技术。

而且，注意的是，实施例可以被描述为进程，该进程被描绘为流程图、流图、结构图或框图。虽然流程图可能将操作描述为顺序进程，然而操作中的许多操作可以并行或同时来执行。另外，可以重排操作的顺序。进程在其操作完成时被终止。进程可以对应于计算机程序中的方法、函数、过程、子例程、子程序等。当进程对应于函数时，函数的终结对应于函数返回至呼叫函数或主函数。

以下描述的系统和方法的各个方面能够在运行操作系统(OS)的任何类型的设备上操作，通过示例，该OS例如但不限于Android OS、iOS、Chromium、Chromium OS、或任何其他的基于Linux的OS，并且通过示例，设备可以是但不限于台式设备、膝上型设备、笔记本设备、平板设备或移动设备。短语“移动设备”包括但不限于无线设备、移动电话、智能电话、移动通信设备、用户通信设备、个人数字助理、手持移动计算机、膝上型计算机、能够阅读电子内容的电子书阅读器和阅读设备和/或通常被个人携带和/或具有某种形式的通信能力(例如，无线、红外、短程无线电等)的其他类型的移动设备。

附图说明

将仅通过示例并且参照附图来描述本文中的各种实施例，在附图中：

图1是Android操作系统的示出了IPC机制的示例的示意图；

图2是示出Linux层中的共享的库函数呼叫与系统呼叫机制之间的相互依赖性的示意图；

图3是根据基于系统呼叫插入(SCI，System Call Interposition)的第一实施例的安全系统的框架基础架构的示意图；

图4是示出实现第一实施例安全系统的图1的Android操作系统的示意图；

图5是由第一实施例安全系统在创建用于Android设备上的新启动应用的新进程监视器时执行的系统操作的流程图；

图6是第一实施例安全系统中的示例性决定生成进程的流程图；

图7是根据所配置的安全策略的用于控制应用组件之间的进程间通信的第一实施例安全系统的示例性配置和Android操作系统架构的示意图；

图8是根据基于函数呼叫插入(FCI，Function Call Interposition)的第二实施例的安全系统的框架基础架构的示意图；

图9A是Android操作系统中的典型PLT/GOT间接机制的示意图；

图9B是根据用于拦截动态链接的符号调用的第二实施例安全系统的修改的PLT/GOT间接FCI机制的示意图；

图10是由第二实施例安全系统在使用嵌入式FCI机制来启动新进程时执行的系统操作的流程图；

图11是由第二实施例安全系统动态执行的切换至基于如由第一实施例安全系统所执行的SCI机制的监视的系统操作的流程图；

图12是对应于新应用的新进程的启动和根据实施例的后期安全策略绑定机制的时间轴；

图13是第三实施例中的适于针对不同用户空间实例提供虚拟化的安全系统的示意图；

图14是示出当在第三实施例安全系统中实现FCI机制以提供虚拟化时执行的系统操作的流程图；

图15是示出当在第三实施例安全系统中实现SCI机制以提供虚拟化时执行的系统操作的流程图；

图16是安全系统可以在其上运行的典型智能电话或平板设备的硬件组件的示意图；

图17是运行操作系统比如Android的设备中的典型存储设备分区的示意图；

图18是Chromium的示意图；以及

图19是在第四实施例中的应用于Chromium的安全系统的示意图。

具体实施方式

1.安全系统的概述

在常规Unix和linux操作系统中，提出了通过拦截对内核的系统呼叫来减轻在应用程序之间的恶意软件IPC攻击。系统呼叫是需要监视的关键机制，这是因为可以使用该系统呼叫来访问操作系统的受内核控制的敏感部分，例如，文件系统、共享存储器和网络连接等。为了设定安全策略，常常需要知道哪个应用调用了特定系统呼叫。在Android OS中，应用可以包括一个或更多个进程。每个进程又可以同时运行一个或更多个线程来执行指令，该指令中的一些指令可以是与内核交互的触发系统呼叫。在常规的Unix和Linux系统中，当由用户经由壳启动二进制时，进程的名称被内核所知。安全系统监视所有系统呼叫，并且基于为进程特定的相关策略来允许或阻止该系统呼叫。这防止恶意进程执行非法系统呼叫，同时允许正常进程执行其功能。这样的安全系统在Android上不能工作，Android使用显著不同的启动和管理其应用的方式。具体地，直到很晚的阶段，内核才会意识到哪些进程对应于Android层中的哪个应用，并且因此非常难于断定的是，确定哪些应用可能正在试图经由系统呼叫彼此通信。

本主题涉及用于Android操作系统或具有相似结构或配置的其他的计算机架构的安全系统。安全系统利用了允许监视用户空间代码而无需修改Android框架或底层Linux内核的方法。具体地，安全系统提供了一种被配置成控制应用之间的进程间通信(IPC)或组件间通信(ICC)以减轻恶意软件可能对敏感应用及其数据执行的攻击的方式。原理上，本文中一些实施例能够针对在Android OS上运行的任何进程来控制并且执行安全策略。这包括在常备(stock)Android中提供的系统服务(比如，SMS服务、活动管理器、服务管理器等)。在此方式下，各种实施例减轻存在于Android服务中的可能被恶意代码利用的漏洞。

基于Android独有的特征即称为Zygote的母进程来实现安全系统。每个Android应用作为从Zygote母进程分出的子进程来运行，并且然后每个Android应用通过下述操作来使自己专用为特定应用：加载特定应用包及包内所有类并且利用最终将通过调用静态主要方法来开始应用的Java反射。通常，每当启动新应用时，安全系统利用Zygote进程来配置与Linux层处的新启动进程相关联的监视实体。在一种形式下，此监视实体可以是嵌入式进程监视器方法或函数，比如添加至存储器中新进程图像的附加代码，或者可选地，在另一形式下，此监视实体可以是与新启动进程相附接并且监视该新启动进程的单独进程。安全系统能够执行安全策略集合，可以通过在安全系统本身内部或外部的下述源来提供该安全策略集合：比如系统管理员、设备用户、第三方服务或系统、Android应用或其组合。

安全系统能够在应用层处实现应用特定安全策略的规范或配置，可以在Linux层执行该规范或配置。将通过特别参考在Android设备上的Android操作系统的示例来描述安全系统。然而，将理解的是，安全系统可以被配置成在与Android或下述任何其他的操作系统或平台具有相似架构的任何其他的适合操作系统上进行操作：是移动的或者否则使用母进程来启动Linux层中的新进程的任何其他的操作系统或平台，比如，但不限于，Linux操作系统、Unix操作系统或者像iOS的移动操作系统。

安全系统可以被配置成监视由内核代表进程执行的系统呼叫。具体地，安全系统被配置成基于与进程相对应的应用的安全策略设定来监视并且实现针对由进程产生的系统呼叫的安全动作。安全动作可以包括：防止系统呼叫执行、修改系统呼叫参数、修改系统呼叫的返回值、根据针对发起系统呼叫的进程规定的安全策略来允许系统呼叫执行或者强制终结该进程。

系统呼叫是由内核代表进程执行的特定函数。该系统呼叫被视为内核执行的作为由进程提供对由内核管理的服务进行的访问的服务的低级操作。通常通过系统呼叫号和硬件中断来使系统呼叫能够用于用户模式代码，并且经常通过链接至进程代码的库函数来调用该系统呼叫。在可执行并且可链接的格式(ELF，Executable and Linkable Format)中，库是特定类型的对象代码，其提供可以从其他的对象代码输入的可重复使用的符号。库的特例是共享对象(或共享库)，其意在被可执行文件和其他的共享对象来共享。

可以静态地或动态地链接共享对象。在前一情况下，在链接时间期间将符号拷贝到对象文件中，而在后一情况中，在执行期间对符号进行解析。可以在进程图像加载到存储器中期间或者在动态链接符号被使用的第一时间对动态链接符号进行解析，这称为懒惰绑定。

libc库是所有基于Linux的系统上的常用组件，并且此外，libc库提供可以用来根据用户模式代码调用系统呼叫的函数集合。Android提供其自己的libc实现，即Bioniclibc。与通常的Linux配置相比，Android的特定特征是：动态地链接libc以减小进程存储占用空间。这意指动态地链接通常被可执行体用来调用系统呼叫的这些符号。

图2提供对此系统呼叫机制的概述。通过示例，当进程1执行至Binder4的ioctl系统呼叫3时，进程1实际上调用由libc.so 5提供的ioctl函数(2)。此函数将调用内核中的ioctl系统呼叫3，并且该操作将在监督模式下来执行6。

安全系统可以使用各种方法或方法的组合来监视并且拦截由被监视的进程产生的系统呼叫，并且可选地在一些实施例中可以动态地在这些方法之间进行切换。在第一示例性配置中，安全系统可以被配置成通过执行系统呼叫插入(SCI，System CallInterposition)来监视系统呼叫，该SCI涉及在Linux层的内核模式下直接地拦截共享对象库5与系统呼叫网关7之间的交互。具体地，安全系统可以实现SCI机制，该SCI机制在Linux层的内核模式下通过系统呼叫网关7监视进程的执行并且直接地检测和/或拦截系统呼叫3。可替代地，在第二示例性配置中，安全系统可以被配置成通过执行函数呼叫插入(FCI，Function Call Interposition)来监视系统呼叫，该FCI涉及在Linux层的用户模式下拦截从进程1至共享对象库5的函数呼叫2，其中正在被监视的函数呼叫集合涉及用于在内核模式下调用系统呼叫的函数呼叫集合。具体地，安全系统可以实现FCI机制，该FCI机制在用户模式下监视进程的执行并且检测和/或拦截至共享对象库的函数呼叫，该函数呼叫意在在内核模式下调用系统呼叫。

参照图3至图7，将描述利用SCI机制或配置的安全系统的第一实施例。参照图8至图11，将描述利用FCI机制或配置的安全系统的第二实施例。参照图13至图15，将描述使用第一实施例的SCI机制和/或第二实施例的FCI机制在设备上针对不同用户空间实例提供虚拟化的安全系统的第三实施例。

2.第一实施例安全系统—SCI配置

概述

在此第一实施例中，安全系统运行系统进程，该系统进程与Zygote进程相附接并且拦截其所有分叉系统呼叫调用，使得无论何时拦截分叉系统呼叫，安全系统都开始监视新进程并且执行针对该特定Android应用的特定安全策略。

在此第一实施例中，安全系统生成用于监视Linux层中每个新启动进程的单独进程监视器(监视实体)。每个进程监视器被配置成实现SCI机制以监视并且拦截由其目标进程产生的系统呼叫。

在此第一实施例中，安全系统使用系统呼叫网关的支持来监视至内核的系统呼叫。安全系统配置或指示系统呼叫网关以在每当目标进程试图在内核模式下调用系统呼叫时就向与该目标进程相关联的的进程监视器发送特定信号。在一个示例中，这通过使用ptrace系统呼叫来实现。当进程监视器调用ptrace来与目标进程相附接时，每当目标进程调用系统呼叫，网关就将暂停目标进程并且向其进程监视器发送信号，并且然后将等待来自该进程监视器的安全动作。后续将更详细地描述ptrace作为SCI拦截机制的使用。

现在讲参照图3至图7来更详细地描述第一实施例安全系统。

安全系统的主要部件

参照图3，第一实施例安全系统200包括三个主要部件或模块，即主要监视器202、应用或进程监视器204和安全系统服务206。

监视器202、204(监视实体)负责执行针对一个或更多个进程的安全策略集合，并且被实现为Linux进程。监视器包含策略执行点以及策略决定点，这将在后续进行描述。在此实施例中，存在单个主要监视器202，其被配置成监视Zygote系统进程208。从此主要监视进程分出进程监视器204的其余部分。可以存在零个或更多个应用监视器204，一个应用监视器用于从Zygote进程被分叉出来的每个Android应用210。当来自Zygote进程的分叉系统呼叫被拦截时，创建进程监视器204作为主要监视器202的子代。与被配置成监视主要Zygote线程的主要监视器202相比较，单独进程监视器204被配置成监视属于与其相附接的应用的所有线程和子进程。

安全系统服务206被配置为应用层中的Android服务，该Android服务向监视器202、204提供对Android层中的所有Android框架功能的访问。在此实施例下，Linux层中的监视器202、204使用客户端服务器通信配置比如但不限于内部Unix套接字来与应用层中的安全系统服务206进行通信。

示例性配置和操作

现在将参照图4至图6中的示例来描述主要模块的安全系统配置和功能的进一步说明。图4对应于图1中描述的架构，并且相似的附图标记表示相似的组件。简要地，属于Android应用10、12的在Linux层中的每个Linux进程18、20具有其自己的分别以52、54示出的所附接的进程监视器。每个进程监视器52、54被配置成拦截所附接的Linux进程18、20代表其所附接的应用10、12执行的系统呼叫的全部或子集合。当每个Linux进程执行系统呼叫时，所附接的进程监视器拦截系统呼叫并且基于与该应用相关联的安全策略来采取安全动作，该安全策略指示Linux进程是否获得了执行该系统呼叫的授权。通过示例，进程监视器可以被配置成：允许系统呼叫，阻止系统呼叫，修改系统呼叫的参数，修改由系统呼叫或者其他适合的安全动作返回的值，或者这些组合。如果Linux进程被授权执行系统呼叫，则进程监视器使得对系统呼叫的执行进行。可替代地，进程监视器可以阻止系统呼叫执行，或者另外地修改系统呼叫参数或者返回值。例如，进程监视器能够检索系统呼叫的参数以及另外地检索系统呼叫返回的值。这使进程监视器能够例如通过过滤出一个或更多个返回值或者在根据应用的所配置的安全策略的执行之前改变或修改系统呼叫的一个或更多个参数来修改系统呼叫。另外地，可以根据系统呼叫的参数的值来采取安全动作。通过示例，进程监视器可以被配置成：针对可能由于受阻系统呼叫而崩溃的应用，修改系统呼叫而不是阻止该系统呼叫。

通过示例，进程监视器52可以被配置成拦截IPC，该IPC使用系统呼叫34来与Binder子系统30进行对接(interface)。这可以通过拦截open和ioctl系统呼叫38来完成，该open和ioctl系统呼叫38的目的地是binder内核驱动器3。然后，如56所示，进程监视器52基于针对应用层中的关联应用10配置的安全策略和从进程执行状态提取的其他参数来决定是阻止系统呼叫还是另外地允许系统呼叫以其原始状态或修改状态进行。

每个进程监视器由主要监视器来创建，该主要监视器是在发起任何应用之前在设备启动时创建的Linux进程，并且将在以后进行更详细地说明。指示应用的授权的安全策略安装在设备上应用层中，并且具体地，哪些应用可以彼此通信或者使用彼此的服务或许可或者存储的其他的敏感数据在应用层中由安全系统服务器可配置并且存储和/或检索，这将在以后进行更详细描述。安全策略可以本地地存储在设备上的存储器中，或者远程地存储在能够被设备访问的外部存储器、服务器或网络上。

通过建立进程监视器作为主控进程并且建立关联Linux进程作为其目标进程并且使用跟踪系统呼叫，每个进程监视器与其对应Linux进程相附接，所述跟踪系统呼叫被配置成使主控进程能够通过检查其存储器和寄存器并且拦截其系统呼叫调用来控制目标进程。在此实施例中，跟踪系统呼叫是进程跟踪系统呼叫(ptrace)。为了使用ptrace，主控进程必须作为根用户或者与目标进程相同的用户进行运行。主控进程将成为目标进程的父代，并且将能够监视并且控制由目标进程创建的所有子进程和线程。

如所提到的，安全系统被配置成通过利用Android OS的配置特征来监视在Android设备上执行的所有应用和对应进程，该配置特征控制对应用的管理和启动。在Android中，通过称为Zygote进程的特定母进程来启动应用层中的所有应用。Zygote进程是有权创建新Android应用及其对应Linux进程的唯一进程。因此，在Android上执行的所有Android应用及其对应Linux进程实际上是此Zygote进程的子代。现在将更详细地描述安全系统的配置和主要模块的操作。

安全系统启动

安全系统作为Android操作系统的一部分启动。如所提到的，安全系统控制母进程或Zygote进程，使得每当开始新Linux进程(对应于Android应用)开始时，可以使新监视器与该进程相附接。通过修改Android操作系统的引导顺序来实现对Zygote进程进行控制。

通过示例，修改引导顺序，使得安全系统的主要监视器置换初始Zygote进程。在引导进程期间，运行初始化脚本并且开始主要监视器。然后启动Zygote进程作为主要监视器的子代。然后主要监视器通过拦截由Zygote进程产生的至内核的系统呼叫来执行跟踪系统呼叫比如ptrace(请求＝PTRACE_ATTACH)，以与子Zygote进程相附接来控制其从其开始的第一时刻的执行。具体地，ptrace(请求＝PTRACE_ATTACH)系统呼叫用来通知内核：每当目标Zygote进程进入系统呼叫或者从系统呼叫退出时，主要监视器应当接收通知。这时，在启动时，主要监视器现在与Zygote进程相附接并且监视该Zygote进程。

在此实施例中，还通过Android操作系统在启动进程期间开始安全系统服务。通过示例，安全系统服务位于系统应用的目录内，使得该安全系统服务在用户可以登录或者可以在Android设备上运行任何用户应用之前启动。如接下来所更详细说明的，当安全系统服务正在运行时，每当从Zygote分叉出新Android应用时，新进程监视器从主要监视器分叉并且与新应用进程相附接。

新启动Android应用的进程监视器的生成

概述

将描述由安全系统执行以生成并且配置新启动Android应用的进程监视器的主要操作的顺序。当安全系统开始时，仅主要监视进程连同安全系统服务一起在运行。主要监视器与Zygote进程相附接并且监视该Zygote进程。新进程监视器由于由Zygote进程产生的分叉系统呼叫调用被创建为主要监视器的子代，每当在Android中启动新应用时呼叫该Zygote进程。具体地，主要监视器被配置成检测由Zygote进程产生的分叉系统呼叫调用，并且创建用于启动的每个新应用的新进程监视器。

参照图5，将通过示例使用用户在其Android智能电话上启动Skype应用的情景。当用户点击其智能电话上的Skype图标时，向Zygote进程62发送消息或信号60来分叉出新进程74，该新进程74在用于Skype应用的DVM的复本中执行。

每当Zygote 62调用分叉系统呼叫64时，将通过内核66来暂停65Zygote 62，并且将由内核经由信号68(例如SIGCHILD)来通知主要监视器且使主要监视器70唤醒。内核分派这些信号，这是因为主要监视器70正在通过ptrace系统呼叫来监视Zygote 62。现在通过从主要监视器70调用分叉系统呼叫来创建新进程监视器72，并且当新进程监视器72被分叉时，该新进程监视器72将与新创建进程74相附接。

由于通过Linux调度器执行的调度，无法保障进程执行命令将允许新进程监视器72在新Linux进程74执行任何系统呼叫之前与对应于Skype应用的新Linux进程74相附接。在一些情况下，新进程74能够开始执行其代码而进程监视器72却不能够对新进程74进行控制，这可能引起安全问题。

为了避免这种情况，主要监视器被配置成将断点76(例如死循环77)注入到Zygote进程代码中，使得当其图像被复制以创建新进程74时，新复本也将包含此断点。新进程74现在包含初始插入其内部的断点77，所以新进程74在由进程监视器去除断点之前将不能够执行任何其他代码。去除断点在进程监视器72已借助ptrace与新进程74有效地相附接之后立刻执行。通过示例，断点可以是断点机器指令、ARM汇编代码中的无限循环、或者暂缓在使用其他指令集合的处理器上的程序执行的任何其他等同方法。下面将进一步描述此实施例的断点注入的示例和剩余进程监视器72生成。

断点注入

如以上陈述的，每当从Zygote 62分叉新Android应用74时，安全系统将断点76注入到Zygote 62中，使得当Zygote 62的图像被复制时，新进程74也将包含断点，并且新进程监视器72可以在新进程74继续其执行之前与新进程74相附接而不会漏掉任何系统呼叫。

如所提到的，“断点”76可以例如是ARM汇编代码中的无限循环。如下使用下面过程来将断点注入76在Zygote进程存储器内的当前程序计数器地址(PC)处。首先，为了恢复Zygote程序执行，Zygote寄存器的状态以及将被断点本身置换的Zygote程序代码应当在主要监视器70的存储器中进行备份。例如，在Zygote的情况下，主要监视器70可以使用ptrace(PTRACE_PEEKDATA)来将Zygote进程图像的一部分拷贝到其自己的存储器中，该ptrace(PTRACE_PEEKDATA)允许从所监视的进程存储器中读取数据。主要监视器可以使用ptrace(PTRACE_GETREGS)来读取Zygote进程寄存器的状态并且将该状态存储在其自己的存储器中。此后，主要监视器70被配置成将PC重设为其先前地址(后续将包含断点)，使得主要监视器70在所注入的断点代码处继续执行。使用ptrace(PTRACE_SETREGS)来将Zygote 62的寄存器R1设定成零，这样做使能断点。接下来，主要监视器被配置成将断点代码注入到Zygote中。主要监视器70包含下述函数：该函数包含执行无限循环(基于R1的值)的内联ARM汇编代码，并且这是注入到Zygote进程存储器中的代码。从主要监视存储器中的函数地址获得作为字节阵列的断点函数机器代码。然后，使用ptrace(PTRACE_POKEDATA)从主要监视存储器将断点代码拷贝到Zygote存储器中程序计数器地址处，ptrace(PTRACE_POKEDATA)允许跟踪器将数据插入到所监视的进程存储空间中。

在断点注入之后的新进程创建

当如上将断点代码注入到了Zygote中时，主要监视器70调用ptrace(PTRACE_SYSCALL)78来通知内核允许Zygote分叉系统呼叫的内核空间代码执行。当分叉系统呼叫执行80时，创建新进程74(在此示例中意在最终是Skype)。新进程74是Zygote 62的克隆，这意指新进程74是存储器中包括所注入的断点的Zygote进程图像的复本。然后，新创建的进程74可以运行，然而将在断点循环77中被暂缓。然后主要监视器70被配置成等待，直到该主要监视器70接收到分叉系统呼叫退出通知。具体地，主要监视器70被配置成针对退出通知进行监视并且拦截该退出通知。

新进程监视器创建

当分叉系统呼叫在Zygote中返回(系统呼叫正在退出)时，将仍然停止66进程并且内核将经由信号82(例如，SIGCHILD)来通知主要监视器70。这时，由于新进程的进程识别(PID)作为分叉系统呼叫的返回值被提供，所以也能够得到新进程的进程识别(PID)。每个进程具有允许内核识别运行的不同进程的唯一PID。主要监视器70被配置成从Zygote检索新进程74的如以84所示的PID。例如，主要监视器70可以使用ptrace(PTRACE_GETREGS)从Zygote进程寄存器R0中检索PID。然后主要监视器70被配置成生成新进程监视器72，该新进程监视器72将与该所检索的PID相附接。

主要监视器70通过执行至内核66的分叉系统呼叫88来分叉出新进程监视器72。当主要监视器进程分叉出90新进程时，新创建的进程监视器72在其执行的开始时是父代主要监视进程的确切复制。这意指，当主要监视器70分叉出新进程监视器72时，进程监视器在其存储器中具有由Zygote 62创建并且从Zygote寄存器检索的新进程74(意在最终是Skype)的PID。

然后，如以91所示，主要监视器70被配置成使用ptrace(PTRACE_POKEDATA)来以原始位置处的原始代码备份置换Zygote62中的断点代码，并且该主要监视器70使用ptrace(PTRACE_SETREGS)来将寄存器重设为其原始存储值。然后，主要监视器借助于ptrace(PTRACE_SYSCALL)来将Zygote的PC重设为其备份值并且请求内核继续Zygote进程，从而经由SIGCONT信号95来恢复Zygote进程并且等待另外的分叉调用。

新创建的子进程监视器72使用如以92所示的ptrace(PTRACE_ATTACH)来用其存储器中的PID使自己与跟踪新Skype进程相附接。进程监视器72还被配置成用为处理器72正在监视的应用特定的点来置换来自主要监视器的主要虚设策略决定点，如以94所示，这在与所监视的新进程74相关联的应用包名称(在此情况下为Skype)被知道之前将都不包含任何安全策略。当进程监视器72被附接时，进程监视器72能够跟踪新进程74，所以进程监视器72可以被配置成用原始代码来置换新进程74中的断点代码，如以96所示，并且进程监视器72可以被配置成借助ptrace(PTRACE_SYSCALL)97来发起对新进程的执行，ptrace(PTRACE_SYSCALL)97将向新进程74递送SIGCONT 98。这采用与如上所述主监视器70置换Zygote进程62中的断点代码的方式相似的方式来完成。所监视的新进程74现在可以开始执行。当进程监视器72与新进程74相附接时，进程监视器72可以拦截并且控制此进程执行的所有系统呼叫。

新进程监视器的安全策略的配置

这时，将存在跟踪/监视Zygote 62的主要监视器70和跟踪/监视新创建的Linux进程74的新进程监视器72，该新创建的Linux进程74还没有专用为Skype Android应用。新Linux进程74尚未执行Skype应用的代码，并且在此早期阶段，无法知道进程将属于哪个应用。这意味着直到新进程74进行专用化才能够加载新进程监视器72的特定安全策略。安全系统被配置成基于应用识别数据来检索特定安全策略或者策略集合并且将其加载到新进程监视器72，该应用识别数据指示新Linux进程74正专用为的Android应用。在此实施例中，应用识别数据是应用的包名称，并且进程监视器72被配置成在其正在监视的新进程74的专用化期间检索该应用的包名称。

为了专用化，新进程74需要检索对Skype应用包名称的获取访问。使得新进程74然后能够将来自应用数据库的Skype应用特有字节代码加载在设备上以用于执行。在专用化进程或阶段期间，Android框架将应用包名称写入到专用化文件(例如，/proc伪文件系统内的/proc/self/cmdline)中。这恰在分叉出新进程74以后并且在使用反射来调用静态主要方法之前发生，这意指尚未执行开发代码。

Android进程Java类(android.os.Process)通过Java本地接口(JNI，Jave NativeInterface)来调用将包名称设定为参数的函数android_os_Process_setArgV0。这将内部地呼叫重设进程argv[0]的ProcessState::setArgV0()方法，该方法有效地改变专用化数据文件(即，以应用包名称来更新专用化数据文件)，并且然后在这之后通过使用prctl(PR_SET_NAME)系统呼叫来设定进程名称。可以通过prctl()系统呼叫设定的进程名称限于16个字节，这意指，在一些情况下，此系统呼叫中的包名称将不完整。当将argv[0]参数设定成专用化数据文件时，不存在由监视进程74生成的系统呼叫，该专用化数据文件实际上包含整包名称。

在此实施例中，代替检查由prctl()函数参数指定的应用名称，进程监视器72被配置成读取在argv[0]被覆盖时设定的专用化数据文件的内容，该专用化数据文件包含全应用包名称。具体地，进程监视器72被配置成检测prctl()系统呼叫何时正以所设定的PR_SET_NAME值退出。当这被检测到时，进程监视器72知道：全应用包名称现在已被写入专用化数据文件。然后，进程监视器72被配置成在检测到prctl()系统呼叫退出时从专用化数据文件中读取并且检索全应用包名称。

当通过进程监视器72获得了包名称(例如，com.skype.apk)时，然后进程监视器72可以检索并且加载为该应用特定的一个或更多个安全策略。具体地，可以初始化进程监视策略，并且执行为该进程特定的策略。包名称被转发至进程监视器的策略决定点，该进程监视器的策略决定点将加载用于所监视的进程的特定策略。为此，进程监视器74可以利用应用层框架中的称为安全系统服务的特定服务，这将在以后来更详细地描述。监视器的操作

概述

每个进程监视器被配置成：通过基于所检索的安全策略相对于所检测的系统呼叫来在Linux层中实现安全动作，针对其附接的新进程执行所检索的安全策略。安全动作可以包括下述动作中的任何一种或更多种动作：允许系统呼叫进行、阻止系统呼叫进行、修改系统呼叫在执行之前的参数或由系统呼叫在执行之后生成的返回值。通过示例，监视进程可以通过控制和指示内核关于内核对所请求的系统呼叫的执行借助于相附接的监视进程来实现安全动作。下面说明执行策略的示例性实现，然而将理解，可以使用替换执行机制。

在此实施例中，主要监视器和进程监视器各自包含两个组件，即，策略执行点和策略决定点。策略执行点负责通过其系统呼叫来跟踪所监视的进程并且负责执行策略，并且策略执行点将来自进程状态的信息提供至策略决定点。策略决定点基于进程状态和分配给策略决定点的策略来生成决定。这些决定被发送至确保这些决定被执行的执行点。

策略决定点使用策略库，该策略库取决于针对每个决定点的安全系统配置并且在配置最终被修改的情况下将在运行时变化。根据监视器(例如，主要监视器或单独进程监视器)所属的类型，监视器将包含不同类型的策略决定点。

主要监视器包含虚设决定点，该虚设决定点被用来拦截fork()系统呼叫并且检索新进程的PID，以生成新应用进程监视器，如先前所说明。

相比之下，进程监视器能够检索与其相应的目标进程相关联的应用包名称并且执行策略初始化。通过示例，可以存在由进程监视器支持的各种类型策略，比如：

●IPC拦截：拦截从所监视的进程生成的进程间呼叫。为此，进程监视器拦截目的地是Binder伪设备(/dev/binder)的这些ioctl()系统呼叫。

●联网：通过在本地或远程地运行的不同进程之间的TCP/IP或者其他的网络协议来控制通信。这包括通过其(例如通过因特网)来控制进程可以联系的外部服务器、客户端或对等网络。

●共享存储：通过共享存储来阻止进程间通信。具体地阻止对下述各种Android共享存储服务的访问：Android共享存储器(ashmem)、进程存储分配器(PMEM)和处理器特有变量(CMEM、NVMAP等)和Android ION存储分配器。而且，可以防止子进程与其父代一起使用共享存储机制。

●文件系统：阻止某些进程访问、创建、读取、修改和/或写入文件系统中的特定文件或文件夹。针对给定应用建立盘配额，并且可以提供沙箱环境，使得每个应用访问其自己的虚拟文件系统。

●电话、短消息服务(SMS，Short Message Service)和多媒体通讯服务(MMS)：阻止进程访问Android上的电话、SMS和/或MMS服务。如果需要，则可以设定策略来防止进程发起电话呼叫或者阻止进程发送SMS或MMS消息至特定号或联系人。

●订户识别模块(SIM，Subscriber Identity Module)访问：阻止进程访问来自安装在设备中的SIM卡的敏感信息；比如集成电路卡标识符(ICCID，Integrated CircuitCard Identifier)、国际移动客户识别(IMSI，International Mobile SubscriberIdentity)、认证秘钥(Ki，Authentication key)、位置区识别(LAI，Location AreaIdentity)、存储的SMS消息、非结构化补充服务数据(USSD，Unstructured SupplementaryService Data)码和联系人列表。

●传感器和其他的硬件访问：阻止进程访问可能存在于设备中的传感器和其他类型的输入或输出硬件；比如相机传感器、麦克风、光传感器、全球定位系统(GPS，GlobalPositioning System)接收器、运动传感器、加速度计、陀螺仪、键盘、按钮、显示器、投影仪、打印机。

●近场通信：阻止进程使用近场通信(NFC，Near Field Communication)或其他类型的无线通信来建立新连接或监视已经处于进程中的通信会话。

●企业权限管理(ERM，Enterprise Right Management)策略：用于操纵企业或数字资产的策略。数字资产意思是指在设备上的存储器或运行存储器中存储的文件。该文件可以例如定义应用或其他数据，比如但不限于承载或定义信息的SMS、邮件、图片或任何其他数据项。通过ERM策略下，当设备上的应用试图访问数字资产时，拥有数字资产的实体(比如企业或组织)保持对数字资产生命周期管理的控制。ERM策略可以被配置并且执行成：控制使用数字资产的方式，或者触发对数字资产的修改或者从设备的完整删除数字资产。ERM策略可以被配置成在应用对数字资产执行访问之前、在对数字资产的访问结束之后、或者在这两种情况下，执行安全动作。ERM策略可以被配置成使得对正在被访问的文件执行安全动作，不管ERM策略在存储器中还是在运行时间存储器(例如，RAM)中。通过示例，ERM策略可以定义在应用访问数字资产之前要执行的下列安全动作中的任何一种或更多种动作：

○修改数字资产以去除或添加信息，例如：

■清除—去除或滤除不应当向访问数字资产的应用公开的任何信息

■版本化—添加与数字资产的版本相关的信息

■水印/指纹—将防篡改信息添加到数字资产中

■时间戳—添加访问数字资产的定时信息

○如果数字资产被加密则对其解密

○删除数字资产

○控制数字资产可以被读取和/或修改的次数，例如：

■对读/写访问进行计数

■记录被读取和/或被修改的数据量

○将访问信息(比如上下文)记入日志

通过示例，ERM策略可以定义在应用已结束了其对数字资产的访问之后要执行的下列安全动作中的任何一种或更多种动作：

○修改数字资产以去除或添加信息，例如：以上面一样的清除、版本化、水印/指纹和/或时间戳

○对数字资产进行加密

○删除数字资产

这些策略加载有与策略数据库中的应用包名称相关联的、被存储在设备上，或者能够远程得到的特定策略配置。可以在需要时在应用执行期间修改并且更新策略。监视器内的一些策略或任何其他的组件可能需要访问仅能够从Android应用层而不是从本机代码层获得的功能，比如访问GUI或不同的Android系统服务，像包管理器和活动管理器等。如将在后面进一步解释的，监视器可以通过使用事务(transaction)而询问在应用层中运行的安全系统服务来使用这样的Android框架功能。

策略执行机制

如所论述的，主要监视器70和进程监视器分别是附加至Zygote的在Linux层中的进程和任何应用进程。跟踪系统呼叫用于将主要监视器70和进程监视器附接至其相应的目标进程。在此实施例中，进程跟踪(ptrace)系统呼叫用于将主要监视器70附接至其目标进程，即Zygote进程62，并且将每个进程监视器附接至其相应的目标进程。一旦执行ptrace系统呼叫以将监视器附接至目标，则目标进程变成其相应监视器或父进程的子代。

关于进程监视器，在此实施例中，ptrace被配置成跟踪目标进程主要线程(默认)并且还跟踪进程线程的剩余部分和子进程。在一些实施例中，这种跟踪比如相对于Android应用是有帮助的，该Android应用通常是多线程应用。通过以这种方式配置ptrace，这确保了进程监视器将接收由每个单线程和进程执行的任何系统呼叫的通知，该每个单线程和进程源自根应用进程。

策略执行机制发生在每个监视器内的策略执行点中。策略执行点通过跟踪所监视的进程系统呼叫并且基于可以从所监视的进程系统呼叫中提取的信息而作出决定来执行策略。

进程监视器(使用例如ptrace(PTRACE_ATTACH))与其相应的目标进程附接，然后进程监视器通知内核：每当内核的目标进程(使用例如ptrace(PTRACE_SYSCALL))执行系统呼叫时内核就应当通知进程监视器。

当执行了此设置时，进程监视器在与所监视的目标进程附接之后进入睡眠(例如，调用waitpid())。这阻止进程监视器在系统呼叫之前被所监视的目标进程调用。当通过目标进程产生系统呼叫时，内核将(例如使用SIGCHILD信号)暂停目标进程执行并且将不再阻止进程监视器。waitpid()函数将返回生成了系统呼叫的线程的ID(TID)以及用于其他目的的一些另外的进程状态信息。这时，进程监视器被配置成检索所监视的进程寄存器的状态，可以从所监视的进程寄存器获得系统呼叫号。线程ID、系统呼叫号和进程寄存器的状态被转发至策略决定点，策略决定点将根据其策略将系统呼叫看作是相关或不相关。如果系统呼叫是不相关的，则系统呼叫将以不作决定的方式立即返回至执行点。如果系统呼叫是相关的，则策略决定点将分析进程状态，并且根据该进程状态，该策略决定点可以或者可以不向执行点返回决定例如要执行的安全动作。后面更详细地说明决定生成机制。在决定点返回之后，如果决定指示继续所监视的进程则将该执行将继续所监视的进程，或者该执行将实现由决定指示的任何其他的安全动作，包括阻止系统呼叫、修改系统呼叫的参数或返回值、请求用于实现用户选择的安全动作的用户输入、或者甚至完全地终止应用进程。在允许进程继续的情况下并且在执行决定之后，进程监视器将通知内核继续进程执行(例如，ptrace(PTRACE_SYSCALL))并且返回休眠(例如调用waitpid())，等待由目标监视进程产生的下一系统呼叫的通知。

策略生成机制

决定是必须执行以执行策略集合的安全动作。每个进程监视器内的策略决定点是负责决定生成的组件，每当策略执行点拦截系统呼叫时就发生该决定生成。在此实施例中，每个策略决定点包含策略集合，该策略集合取决于用于所监视的应用的监视器类型和安全系统配置。与用户定义策略(在应用层中指定的策略)相比较，这些策略(还被认为是低级策略)被定义在安全系统本身内。用户定义策略可以被翻译成一个或更多个低级策略，并且可以根据其语义影响一个或更多个监视器。

执行点触发决定生成机制。在拦截系统呼叫之后，执行点检索产生进程的用于进程的寄存器的状态，并且检查这样的呼叫是进入还是退出。策略决定点以及策略具有两个条目点(entry point)，一个条目点用于进入系统呼叫，而另一个条目点用于退出系统呼叫。这是由于可以在每个点处检索的信息不同，所以可以在每个阶段期间作出不同的决定。然后，执行点向决定点内的特定条目点转发系统呼叫号、进程寄存器的状态和生成了这种系统呼叫的TID(此信息在本文中称为进程状态)。进程状态被传递至可以返回或可以不返回决定的策略中的每个策略。在一种形式下，只考虑由策略返回的第一决定，并且丢弃其余决定。在另一形式下，这可以通过对每个策略分配不同的优先级或者使用其他的选择机制来修改，在此实施例中，即使已经通过策略中的一个策略生成了决定，在其余策略需要进程状态来跟踪进程历史的情况下，仍然向其余策略传递进程状态。

在此实施例中，策略不是整体构件，策略不是由可以属于称为动作模块的一个活更多个策略的可重复使用模块来产生。动作模块与唯一系统呼叫相关联并且从进程状态中提取信息，以提供可以由策略用于生成决定的信息。动作模块，与决定点和策略本身相同，提供两个条目点，一个条目点用于进入系统呼叫，而另一个条目点用于退出系统呼叫，然而与决定点和策略本身相比，针对每个线程来特定动作模块，所以动作模块除了在其被建立时之外不需要线程标识符。每个政策指定针对每个线程实例化并且在所监视的Android应用(以及子进程)内运行的动作模块列表，这样使得无论何时调用策略条目点，如果针对该线程的动作模块列表不存在，则创建该动作模块列表，并且一旦线程或进程退出，则去除该动作模块列表。在此方法下，可以独立地跟踪每个线程执行并且可以执行附加的安全检查。

当调用策略条目点时，策略条目点将通过针对TID的所有动作进行循环，该TID生成了与该特定系统呼叫相关联的系统呼叫。这些动作模块中的任何模块应当认为系统呼叫调用对其是有意义的(例如，一些特定设备上的ioctl()或者就在套接字描述符上的open())，该策略将检查通过这些动作模块收集的数据并且生成决定(安全动作)。然后将决定返回至策略决定点，该策略决定点将根据其他的策略结果来决定是否应当将该决定发送回到执行点。最后，如果决定点已返回了任何决定，则执行点将确保作出决定以执行生成了该决定的策略。图6中图示地示出了此进程。

安全系统服务

概述

安全系统服务是应用层中的Android系统服务，该Android系统服务向Linux层中的监视器暴露所有Android框架功能。安全系统服务在任何用户应用之前在启动时运行。与向其他的Android应用或服务提供服务的正常Android服务相比，在此实施例中此服务不通过预期动作过滤器或AIDL接口来暴露其功能。而是，安全系统服务通过应用层与Linux层之间的通信链接或进程向进程监视器提供其功能。在此实施例中，应用层中的安全系统服务与Linux层中的进程监视器之间的通信经由请求Unix套接字而发生，即安全系统服务收听TCP端口上的请求。这些请求称为事务。每个事务具有唯一ID并且可以包含通过进程监视器设定的在服务中被处理的零个或更多个参数，该事务最终返回向进程监视器返回的结果。

每个事务具有作为进程监视器的客户端部分和用安全系统服务表示的服务器部分。客户端部分设定事务标识符(事务ID)和参数，并且将通过套接字串行化的事务标识符(事务ID)和参数发送至安全系统服务。事务是同步的，所以等到已处理了事务阻止进程监视器。安全系统服务被配置成等待对安全系统服务套接字的请求。每当接收到新事务时，安全系统服务检索事务ID，并且建立事务的服务器部分，该服务器部分将来自套接字的参数并行化，并且使新事务进入线程池队列中。当存在处理事务的可得到线程时，事务运行并且执行其功能。该事务将返回，并且串行化结果将被发送至请求进程监视器。为了完成此进程，进程监视器接收被并行化的事务响应，并且将除去阻止从而继续其执行。在此实施例中，通信链接可以使用用于保护安全系统服务与进程监视器之间的通信的机密性的传输层安全(TLS，Transport Layer Security)。将理解的是，在包括但不限于共享存储空间等的其他的实现中，其他的通信链接或机制可以用于实现安全系统服务器与进程监视器之间的通信。

在应用层中操作以用于访问Android框架的服务的安全系统服务允许通过标准Android接口(比如应用)来规范每个应用策略。而且，安全系统服务允许进程监视器处理Android实现IPC呼叫的特定方式。安全系统服务向进程监视器提供至Android服务的上级的条目点，并且在这样做时，进程监视器能够执行其策略。下面进一步说明这些方面。

示例—设定安全策略

参照图7，将通过示例来描述示出在Android设备100上的安全系统服务的功能的安全系统的示例实现。Android设备具有在应用层42中运行的Skype应用102和MyBank应用104，Skype应用102和MyBank应用104各自具有分别在Linux层24中的对应Linux进程106、108或者被映射至该分别在Linux层24中的对应Linux进程106、108。对应进程监视器110、112分别与每个Linux进程106、108相附接。在Linux层中还示出了Zygote 114及其附接的主要监视器116。安全系统服务120被示出作为正常Android服务在应用层42中运行。通过示例，示出了在与Skype应用相关联的进程监视器110与安全系统服务118之间的TCP通信链接，并且在任何其他的进程监视器与安全系统服务之间还存在或者可以建立相似通信链接。

与Skype应用相附接的进程监视器110可以使用安全系统服务120的用于加载为Skype应用特定的策略的功能。具体地，当进程监视器110正在进行自身配置时，进程监视器110检索与(如先前说明的)其所附接的进程106相关联的应用包名称，并且然后使用此应用识别数据来从安全系统服务120中请求用于那个应用的一个或更多个安全策略，该安全系统服务120已访问策略数据库，比如存储了策略的策略配置文件。针对应用的安全策略可以存储在设备永久存储装置上的策略配置文件中，在存储器中，或者可替代地在服务器或网络或能够通过安全系统服务访问的其他设备上的远程位置中。安全策略可以按照各种方式被配置并且被存储在策略配置文件中。策略可以经由定制安全系统应用配置有GUI，该GUI可以在应用层中进行启动，并且可以由用户或者系统管理员来操作，自动地在应用安装期间借助应用许可来设定，从通过第三方操作的网络或服务器来检索，或者可以按照任何其他适合方式来配置。

通过示例，MyBank应用104是用户想要保护的敏感应用。用户不信赖Skype应用102以通过IPC呼叫MyBank应用。安全管理员可以定义高级策略比如：Skype不向MyBank授权IPC。此策略必须被翻译成进程监视器110可以执行的低级策略。例如，为了控制应用之间的IPC通信，可以实现低级策略比如：IPC策略，其拒绝用““CallingAppPackName”表示的应用与采用“TargetAppPackName”的应用之间的IPC呼叫。策略可能是：拒绝IPC策略(CallingAppPackName、TargetAppPackName、类型)。此策略采取下述量作为变元：呼叫应用的包名称、目标应用的包名称和指示目标是应用还是服务的参数。针对我们的情况，当与Skype相附接的进程监视器110在初始化时联系安全系统服务120来请求Skype策略时，安全系统服务将从策略数据库检索相关策略并且代表MyBank app用为Skype指明包名称的参数进行答复，并且此MyBank是应用。进程监视器110然后可以加载IPC策略如下：拒绝IPC策略("com.skype.app"、”com.mybank.app”、应用)。

监视IPC系统呼叫

在此实施例中，安全系统服务的其他主要功能将帮助进程监视器解析其附接的监视进程正试图与其通信的应用名称，使得其然后可以执行与该IPC相关的任何具体策略。在Android中，IPC呼叫机制使用用于执行称为“意图(intent)”的远程方法调用的特定类型的消息。意图表示了远程过程呼叫的抽象化，并且是Binder管理不同应用之间的IPC所采用的主要方式。在Android中存在两种被支持的意图：显式意图和隐式意图。显式意图定义哪个应用是意图的接收器。进程监视器可以直接地捕捉显式意图并且从正在由所监视的进程执行的关联系统呼叫参数提取目标应用(或其包名称)。隐式意图指示应当被执行但不是目标应用或服务的动作。然后，直到Android框架才找到意图的最佳匹配目的地。Android运行时间和具体地活动管理器决定哪个活动将是意图的目标。活动管理器联系包管理器来解析隐式意图。包管理器是保持与Android设备上安装的应用和服务有关的一些信息的系统服务之一。

从进程监视器角度看，当其监视的应用正在使用隐式意图执行IPC系统呼叫时，进程监视器能够捕捉意图并且提取其内容，然而所提取的信息不足以用于评价其安全策略。IPC安全策略需要目标应用作为参数，但是隐式意图仅提供对所请求的服务的描述。由于包管理器是在Android顶部的应用层中运行的服务，所以进程监视器不能够直接地对其进行访问。然而，进程监视器被配置成经由Unix套接字与在应用层上运行的安全系统服务进行交互并且通信，并且该进程监视器可以向安全系统服务发送针对表示与隐式意图相关联的目标应用的信息的请求，使得该进程监视器可以执行与该意图相关的相关安全策略。

例如，参照图7，假定：MyBank应用104具有方法“myPrecious”，该方法被调用用于“得到一些珍爱东西”；以及Skype应用102想要向具有带有描述“得到一些珍爱东西”的“myPrecious”方法的应用发送隐式意图。在Android中(在没有安装安全系统的情况下)，当Skype应用102通过Binder发送意图时，Binder将询问包管理器哪个应用具有带有描述“得到一些珍爱东西”的“myPrecious”方法。包管理器将以MyBank应用104进行答复。因此，Binder将向MyBank应用发送意图，该MyBank应用将答复向Skype应用102给出珍爱东西的请求，这可能导致安全问题。当在Android设备上安装了安全系统时，以上进程如下说明地进行变化以最小化这种安全风险。

当在Android设备上安装了安全系统使得进程监视器110与Skype应用相附接时，其将拦截在隐式意图从Skype应用发送至Binder时生成的系统呼叫。进程监视器110被配置成检索意图内信息，但是最初进程监视器中的策略不能确定目标应用的尚不知道的包名称。进程监视器110不能够直接地访问Android层中的包管理器，但是安全系统服务120能够如此，这是因为安全系统服务120是在Android顶部上应用层处运行的标准Android服务，具有用于进程监视器的特别通信链接即TCP连接。当进程监视器110拦截具有隐式意图的系统呼叫时，该进程监视器被配置成拷贝应用描述和方法，并且将其与对目标应用的包名称的请求一起通过TCP链接118发送至安全系统服务120。安全系统服务120被配置成接收并且处理事务，并且使包管理器提供目标应用的包名称，该目标应用满足基于其配置的描述。包管理器会将“com.mybank.app”包名称返回至安全系统服务，该安全系统服务会使用相同的TCP链接118将该包名称转发至进程监视器110。现在，进程监视器110具有包名称信息并且能够评价且执行其安全策略。在此情况下，上述策略将被评价，并且由于其是拒绝策略，所以动作将被拒绝。

3.第二实施例安全系统—FCI配置

概述

在此第二实施例中，安全系统利用Zygote进程在每个新启动进程中配置嵌入监视实体，比如嵌入进程监视方法或函数。在每个新进程启动期间或者在每个新进程启动之后的某个时间，其嵌入监视实体被加载或配置有与应用层中应用相关联的的安全策略，Linux层中进程对应于应用层中应用。在此实施例中，安全系统使嵌入监视实体能够使用FCI机制或配置来检测并且拦截由其进程产生的动态链接的符号调用。如将在后续更详细地说明的，FCI机制在Linux层的用户模式下拦截针对共享对象库的动态链接的符号调用(其可以意在在Linux层的内核模式下调用一个或更多个系统呼叫)，并且将该动态链接的符号调用重新定向至进程内的嵌入监视实体。嵌入监视实体处理与检测的符号调用相对应的函数呼叫，并且基于针对进程而配置的安全策略来实现安全动作。与第一实施例安全系统一样，安全动作可以根据下述动作而改变：例如，允许函数呼叫进行、修改函数呼叫的参数和/或返回值中的任意一个参数或返回值、或者停止函数呼叫，这全部将对在内核模式下执行或调用的任何最终系统呼叫产生相应影响或将产生任何其他的侧面影响。

参照图8，将说明第二实施例安全系统300的FCI机制的总体配置。在此实施例中，安全系统被配置有代理函数集合(代理函数库)302。代理函数库可以是动态链接至每个进程的共享库，使得每个进程可以被认为具有其自己的代理函数库，如将在以后所说明，在此实施例中，该代理函数库采用代理偏移表(POT，Proxy Offset Table)的形式。当进程304调用函数呼叫306而不是如先前参照图2所述直接进入共享库308时，由代理函数库305拦截动态链接的符号调用306。此代理函数库302或者拦截模块提供动态链接的符号的定制版本，该动态链接的符号的定制版本将调用或函数呼叫重新定向至与进程304相关联的监视实体310，如以312所示。该动态链接的符号的定制版本与其意在拦截的实际符号具有完全相同的签名(并且可以具有相同的名称)。

图8为了清楚而示出了相对于其关联进程304为单独模块的监视实体310，然而在此第二实施例中，监视实体310是在进程304内提供或操作的嵌入方法或函数。基于在监视实体310中配置的用于进程304的一个或更多个安全策略，监视实体310对所检测的函数呼叫实现安全动作或决定。通过示例，监视实体可以允许、拒绝或修改函数呼叫的执行，或者完全终止产生函数呼叫的被监视进程304。如果允许执行(采用其原始形式或修改形式)，那么监视实体将实际函数呼叫调用(采用其原始形式或修改形式)转发至包含原始符号308的实际共享对象库，如以314所示。此后，与以往共享对象库308对系统呼叫网关316执行实际调用一样来执行对实际共享对象库可以在内部调用的函数和任何系统呼叫的执行，如以318所示，并且如先前参照图2所述。如果拒绝执行，则监视实体将禁用对符号的调用以防止函数呼叫执行，并且可以根据将被调用的关联系统呼叫的性质和/或与进程相关联的安全策略来可选地执行其他附加的安全动作，比如终止整个进程或者将值或错误代码返回至进程来防止崩溃，如先前相对于第一实施例安全系统所论述。

以上FCI机制可以采用各种形式来实现。具体地，可以利用各种方法将来自实际共享库308的函数呼叫的执行路径重新定向至由安全系统创建的新代理函数库302，而无需修改Android操作系统和与应用层中应用相关联的应用代码。现在将更详细地描述实现FCI配置以将执行路径重新定向至代理函数库302的各种形式。

第一形式—LD_PRELOAD变量

在第一形式下，第二实施例安全系统使用LD_PRELOAD环境变量来实现FCI机制。LD_PRELOAD是被运行时间链接器使用的环境变量，并且可以用于在可执行加载阶段在其他库之前链接用户特定共享对象。在此第一形式下，安全系统可以在新进程304被启动时配置LD_PRELOAD变量来告诉运行时间链接器链接代理函数库302。

在此形式下，LD_PRELOAD方法仅在进程正在被启动时才是有效的。当在执行时，如果进程加载来自任何共享对象的新符号，则LD_PRELOAD设定不会影响新加载的符号。具体地，来自共享对象的加载代码可以绕过代理函数库302直接地向共享对象库308调用函数呼叫。第二形式—PLT/GOT插入

在第二形式下，第二实施例安全系统可以通过使用PLT/GOT插入来实现FCI机制。将参照图9A和9B来更详细地描述第二形式。

在Android中，使用标准NDK工具链编译的所有二进制，具体地负责启动Zygote母进程(/system/bin/app_process)的二进制链接至Bionic libc库308(图8所示)。与正常Linux分布相比，此库被动态地链接，并且此库的代码在加载于存储器中时被所有运行应用所共享。参照图9A，将进一步描述PLT/GOT间接机制。共享对象(或共享库)是特定类型文件，该特定类型文件通过可执行且可链接格式(ELF)328来定义。在执行期间，通过应用代码331对由共享对象提供的符号的调用被翻译成至过程链接表(PLT)330内部的条目的跳指令，数据结构被定义为ELF规范的一部分。此PLT 330的条目是存根函数(stub function)，该存根函数在被调用时执行进入全局偏移表(GOT，global offset table)334)内条目的跳指令333(还通过ELF规范来定义)。最后，GOT 334中条目是加载在驻存有实际符号的存储器中的共享对象代码337内的目标符号的真实地址335。

在第二形式下，第二实施例安全系统300被配置成通过修改如图9B所示来描述的PLT/GOT间接机制来实现FCI机制。在第二形式下，安全系统被配置成重写GOT中的条目以将函数调用指向新代理偏移表(POT，Proxy Offset Table)340。340中的每个条目指向在进程中嵌入的嵌入监视实体310，并且调用监视实体310内部的策略执行点(PEP，PolicyEnforcement Point)339。然后，监视实体310对照为进程配置的安全策略来分析正被调用的符号，并且实现安全动作。如果监视实体310允许符号调用，则将通过监视实体来调用实际符号337。

在此实施例中，安全系统被配置成通过用指向POT 340中包裹函数(wrapperfunction)345的地址来改变GOT中原始地址来修改GOT 334条目。原始地址作为函数指针341存储在POT 340中。函数指针341与原始函数具有相同的签名：函数指针341没有采用任何变元并且返回整数。POT中的将从GOT 334中调用的条目还与原始函数具有相同的签名。当应用331调用此函数func时，POT 340中的包裹函数将执行下面步骤。首先，该包裹函数将调用监视实体310中的PEP 339方法enter 343。此enter方法通知PEP 339：应用331将要执行对函数func的调用(注意，尚未执行该调用)。PEP 339将获取函数的名称和函数参数(在此示例中，func不采用任何参数)。PEP 339会将此信息传递至监视实体310中的其他模块以决定安全动作。

在对监视实体内部的策略或者被监视实体访问的策略进行评价之后，如果PEP339返回343“允许”，那么可以执行函数func 347。在此示例中，函数func返回整数。在函数返回之后，安全系统被配置成在函数完成了其执行并且返回了其值之后执行二次检查。这使监视实体能够在需要时通过为调用该函数的应用331而设定的安全策略来检查并且修改函数的返回值。例如，监视实体可以去除一些敏感信息或数据，或者可以用伪返回值来修改一个或更多个返回值。通过调用监视实体310内部的PEP方法exit 349并且提供由函数返回的值作为变元来执行此二次检查。

如果安全策略指示出不应当允许应用331调用函数func，PEP 339的enter方法还可以返回“拒绝”值342。在此情况下，将函数特定错误代码344返回至应用331。可替代地，PEP 339的enter方法可以返回“终止”346应用的决定。在此情况下，包裹函数345将执行终止进程及其应用的退出。

GOT被填充的方式取决于程序的编译设定，即，操作系统和/或应用。通过默认方式，GOT条目使用懒惰加载方法来填充。在进程首次调用动态链接的符号时，函数的实际地址被解析并且被插入GOT中。这意指需要GOT的存储页面能够在运行时间修改。另一选项是重定位只读(RELRO，Relocation Read Only)。此选项指示：运行时间链接器必须在进程的加载时间期间解析GOT中的所有依赖项。此选项仍包括在运行时间修改GOT存储页面，但是这些修改仅在加载时间来进行。最后，存在与RELRO执行相同操作的FULL RELRO选项，但是当GOT被填充时，存储页被设定为只读。这意指仅进程本身可以改变这些条目。通过示例，Android Jelly Bean(版本4.1)Google使用用于编译Android和系统应用代码的FULLRELRO选项。

在第二形式下，POT 340表示代理函数库302，该代理函数库302拦截来自其关联进程的动态链接的符号调用，并且将该动态链接的符号调用重定向至嵌入监视实体310。在一个示例中，安全系统被配置成在每个新启动进程中注入修改GOT条目的代码。当监视实体正在相同进程内运行时，通过使用系统呼叫mprotect()，安全系统可以将GOT 334的存储页面设定为可写，可以执行修改，并且然后可以执行mprotect()系统呼叫来设回如在FULLRELRO中使用的只读许可。

在另一示例中，安全系统可以使用是C库的Libhijack以在执行时间期间向每个新重启动进程中注入用于修改GOT条目的代码。具体地，安全系统可以使用Libhijack来修改目标进程的GOT条目以重新定向函数呼叫。Libhijack利用用于修改目标进程的存储页面的ptrace系统呼叫。然而，当Libhijack基于ptrace时，在FULL RELRO被使用时比如在AndroidJelly Bean中不能够使用Libhijack。

第三形式—组合LD_PRELOAD变量和PLT/GOT插入的混合FCI机制

在第三形式下，安全系统实现将LD_PRELOAD的简单与PLT/GOT插入的鲁棒性相组合的混合方法来实现FCI机制。如以下所进一步说明的，在此第三形式下，安全系统利用母进程Zygote来配置并且实现FCI机制。

参照图10，首先，init.rc文件被修改以将针对母进程Zygote的LD_PRELOAD值设定成指向代理函数库302a。当安全系统最初仅关注Zygote对fork()系统呼叫的调用时，安全系统在Zygote进程中针对fork()创建一个单代理函数。当从Zygote 350分叉出进程351时，置于代理函数库302a中的与原始fork()函数具有相同的签名和名称的分叉代理函数将被呼叫。这个被修改的分叉代理函数将仅仅将调用转发352至libc库308中的真实分叉函数以分裂出新子进程353。当子进程353被创建时，子进程353将是父进程Zygote 350的准确拷贝或克隆354。这意指还将在新子进程353中拷贝Zygote的库。具体地，还将使修改的LD_PRELOAD设定对子进程有效，使得该修改的LD_PRELOAD设定指向其自己的代理函数库302b。当内核308完成分叉时，内核308向父Zygote 350和子进程353二者返回值。然而，在返回实际进程之前，libc库308将通过两个进程的代理函数库302a、302b。用于Zygote进程350的fork()代理函数302a将仅返回355、356而无任何修改。然而，子进程353的代理函数库302b将在返回358、359之前使用上述mprotect()系统呼叫方法来执行GOT条目357的修改。现在从自身起，将通过修改的GOT条目来拦截由子进程353执行的任何函数呼叫。

当新进程353专用化为预期应用时，嵌入的进程监视方法(监视实体)将链接或加载用于应用的适当安全策略。如先前指出的，与其中进程监视器是与其目标进程相附接的单独进程的第一实施例安全系统相比，监视实体被嵌入，或者是其正在监视的同一进程的一部分。在此第二实施例中，嵌入的进程监视方法已访问新进程正专用化成的应用的包名称，并且因此可以按照与先前参照第一实施例安全系统描述的方式类似的方式来检索适当安全策略。

在此方式下，通过PLT/GOT修改来针对新子进程353实现FCI机制的主要优点是：即使子进程加载外部库作为共享对象，PLT/GOT修改也仍将是有效的。但对于如在第一形式下仅使用LD_PRELOAD而言却不可能是这样的。由于系统仅关注拦截来自主要Zygote可执行代码(而非来自被其使用的其他共享对象)的fork()符号调用，所以使用LD_PRELOAD FCI机制是合适的。

如果新进程353调用分叉来开始新子进程，则会将所有GOT修改拷贝至子进程存储器中。因此，子进程将具有带有其自身代理函数库的嵌入FCI机制，并且也将通过其自身的嵌入进程监视方法来进行监视。

第三形式混合FCI机制的部署

为了在Android中部署安全系统，将在安全系统共享对象中编译安全系统代码。将在是标准文件夹的/system/lib or/vendor/lib中部署共享对象，在Android中库位于该标准文件夹中。可替代地，可以在任何其他文件夹中部署安全系统代码。

为了实现安全系统，改变init.rc文件以将环境变量LD_PRELOAD设定成指向安全系统共享对象。当在引导时间开始Zygote时，运行时间链接器将在任何其他库之前加载安全系统共享对象。这样，当Zygote执行分叉时，将调用针对fork()符号的代理函数而非由Bionic libc提供的实际fork()。

安全考虑

对由于使用第三形式的FCI混合机制引起的几种安全考虑进行论述。

首先，通过此方法，安全系统代码将是目标进程图像的一部分。正因如此，目标进程可能执行修改GOT条目的代码来指向原始存储地址，从而绕过监视实体。为了避免此问题，一旦修改了GOT条目，安全系统产生借助于mprotect()函数呼叫只读的GOT条目的存储页面。这意味着在目标进程想要改变GOT条目的情况下，首先，目标进程必须呼叫mprotect()函数呼叫来使存储页面可写。然而，安全系统可以被配置成拦截此呼叫(通过其在代理函数库中的mprotect()代理函数)，并且经由嵌入监视实体来拒绝其执行。作为示例，如果安全系统检测到进程正在试图除去对属于GOT的存储页面的保护，则可以拒绝执行。

使用由此实施例提供的方法，根据静态链接库使用的代码作为二进制文本区域的一部分被包括，这意味着该代码不在安全系统的控制下。然而，此方法假定已被静态链接的所有代码是受信任代码。安全系统的主要关注是可以在运行时间加载的那些共享对象。

可以借助于提供在所需参数之后的系统呼叫号的syscall()函数呼叫来调用系统呼叫。这可以绕过针对这种系统呼叫的安全系统。为了避免这种情况，安全系统可以被配置成拦截syscall()库函数并且检索与进程想要执行的系统呼叫相对应的系统呼叫号。代替使用来自原始库的系统呼叫，监视器可以将执行重定向至与这种系统呼叫相对应的代理函数。

函数dlsym()将通过dlopen()返回的动态库句柄和符号名称串作为参数，并且返回该符号被加载到存储器中的地址。作为特定伪句柄，可以向其传递RTLD_NEXT常量，以便于在当前库之后在搜索命令下找到函数的下次出现。这意味这必须以递归方式修改GOT中条目。这还适用于其中共享对象利用第二共享对象的情况。为了能够拦截来自第二共享对象的函数呼叫，我们需要执行递归拦截来避免此问题。

动态切换至SCI机制—Ptrace

存在仍有可能绕过第三形式混合FCI机制的情况。

例如，进程可能想要借助于dlopen函数呼叫从随机共享对象加载不受信任符号。GOT条目的修改针对此代码将不是有效的，这是因为程序二进制没有链接至这种共享对象，所以对于这种符号在PLT/GOT中没有条目。

另一问题是联机汇编代码，该联机汇编代码允许应用绕过libc库以便于通过机器代码调用系统呼叫。在此情况下，代码被编译器输入二进制文本区域内，并且无库呼叫被调用，这是因为调用系统呼叫的机器代码在编译时间被输入该二进制文本区域内。这意指可以使用此机制来绕过安全系统。

然而，安全系统可以被配置成检测以上行为。针对dlopen函数呼叫的情况，进程必须调用由libdl.so提供并且被动态链接的符号。安全系统提供针对此符号的代理函数，这意味着，安全系统在运行时间可以控制加载哪些共享对象。针对联机汇编代码问题，安全系统可以被配置成解析不受信任本机代码以检测下述指令：该指令生成硬件中断来改变成监督模式(SWI#0on ARM)。

在以上两种情况下，当针对第一实施例安全系统进行动态切换时，安全系统可以动态地切换至使用SCI机制比如ptrace()。通过参照图11的示例，当进程370调用dlopen函数呼叫371时，安全系统使用在其代理函数库372中的dlopen代理函数来拦截函数呼叫。dlopen代理函数将被配置成分叉出新进程，该新进程是包括代理函数库376的运行进程370的准确克隆377。

当分叉返回378在克隆的进程376上时，克隆的代理函数库376将禁用代理函数库并且调用具有选项PTRACE_TRACEME的ptrace系统呼叫379。此选项告诉内核该子进程375想要被另一进程370监视。子进程375还提出停止SIGSTOP 380，直到父进程370允许子进程375恢复其执行。当子进程375恢复其执行时，子进程375将继续dlopen 384操作，并且共享对象(新本机代码)将被加载在其图像内，使得共享对象的符号将能够被进程访问。

另一方面，监视父进程还将停用代理函数库372，并且将通过调用具有选项PTRACE_SYSCALL 382的ptrace来递送信号383以用于使新进程375继续其执行直到其下一系统呼叫为止。

父进程中的监视实体然后可以基于与父进程相关联的安全策略来执行关于所拦截的系统呼叫的安全动作。换句话说，父进程370与子进程375相附接，使得父进程370被配置成如在第一实施例安全系统中一样经由ptrace监视由其目标子进程375产生的系统呼叫。

当没有加载共享对象时，可以终止克隆进程375并且将如在代理函数的FCI机制拦截函数呼叫之前一样来恢复主要父进程370的执行。例如，监视实体可以被配置成检测对dlclose的呼叫，该呼叫通知dlcolse共享对象未加载。

4.定时(后期/延迟/懒惰)安全策略绑定

概述

将来自安全策略数据库或策略配置源的安全策略加载或链接至与对应于新启动应用的新进程相附接或者嵌入在该新进程内的监视实体涉及获得正确识别应用(这种进程已专用为该应用)的信息。

如先前论述的，在常规Unix和Linux操作系统中，已提出了安全系统，该安全系统基于它们从壳命令行直接得到的启动信息将安全策略与新进程相链接，该启动信息包含新启动应用的应用名称作为变元。参照图12，在402处，这种安全系统基于初始启动指令400例如壳命令行变元来链接或者检索将一个或更多个安全策略与新进程相链接所需的应用识别数据。此早期安全策略绑定机制意味着安全策略甚至在新进程的实际应用代码开始专用化之前就与新启动应用相关联。关于此方法的主要问题是恶意应用可能通过后期专用为与在壳变元中使用的应用不同的应用来愚弄系统：作为结果，错误安全策略集合可能与新进程相关联。

参照图12，在至少一些实施例中的安全系统使用后期安全策略绑定机制，其中，一个或更多个安全策略与新启动进程的链接或关联被定时或者延迟，直到达到预定义识别阈值或者发生了预定义事件为止，比如至少直到在通过母进程分叉出404新进程时或在这之后为止，如以406所示。例如，直到分叉出404新进程时或在这之后才确定或提取与新进程正在专用为的应用或应用类型相对应的应用识别数据(其被用于与一个或更多个正确安全策略相链接或相关联)。在此描述中，安全策略与进程相“链接”或“关联”的短语意思是指：提取新进程将专用为的在应用层中的应用的应用识别数据(例如，应用名称、签名或者包名称)，使得基于该应用识别数据和/或将一个或更多个安全策略配置或加载进与新进程相附接或者嵌入到新进程中的监视实体内的实际配置或加载来确定一个或更多个安全策略。

在一种形式下，在已分叉出404新子进程时或者就在这之后不久链接安全策略。在另一形式下，当新子进程正在专用化408或者一旦新进程已经专用化时将安全策略与应用代码相链接。在另一形式下，在新进程在专用化之后开始执行410加载的应用代码时或者在这之后链接安全策略。在另一形式下，仅在达到预定义识别阈值时才链接安全策略，该预定义识别阈值对应于采集或者接收足够的或充分的数据或证据，而该数据或证据指示或确认：在Linux层中启动的新进程对应于用户打算启动的在应用层中的应用。

以上后期安全策略绑定机制在Android操作系统的环境中可以应用于或实现于以上描述的第一实施例安全系统或第二实施例安全系统中任意一个。另外地，此后期策略绑定机制可以应用于其他的操作系统，包括Linux或者Unix操作系统、iOS或者随着母进程一起启动新进程的任何其他的操作系统，如将在下面仅通过示例所说明。

后期安全策略绑定机制可以实现在第一实施例或第二实施例中描述的安全系统的环境中，或者可以实现在需要将一个或更多个应用特有或一个或更多个应用类型特有安全策略与执行该应用的新启动进程相关联的任何其他的操作系统安全系统的环境中。

Android操作系统

如先前针对第一实施例安全系统所说明的，在新分叉子进程的专用化进程的最后步骤期间检索应用识别数据(例如，全应用包名称)。具体地，当安全系统被配置成依赖由专用化408成为应用的子进程执行的最后步骤时，这时，该应用将其应用名称设定至例如/proc文件系统内的专用化数据文件中。当应用已专用化时，应用会在prctl系统呼叫退出之后将其名称设定到/proc/self/cmdline文件中。这在分叉出404进程之后并且在新进程开始执行410实际应用代码之前发生。

还可以使用用于提取或者识别进程已专用为或正在专用为的应用或者应用类型的其他方法，并且将在后续更详细地说明一些其他的示例。

Linux操作系统

还可以在将安全系统部署或实现在Linux操作系统上时使用后期安全策略绑定机制。在Linux中，使用/proc文件系统以用于保持关于运行进程的信息(如在Android中)，就Android而言，在进程已专用化之后，与新启动进程相关的应用识别数据被设定在/proc文件系统中，并且可以被检索以使一个或更多个适当安全策略能够与新进程相链接。

iOS—移动操作系统

还可以在iOS平台部署所描述的安全系统。第一实施例安全系统在iOS上工作的主要要求是：(i)用于跟踪进程执行的系统呼叫插入机制比如ptrace等；以及(ii)用于将进程监视器与进程相附接的机制。

当iOS是基于Linux的OS时，存在ptrace工具。然而，在iOS中，ptrace经常被应用开发者用来拒绝调试器与其应用相附接。ptrace选择PT_DENY_ATTACH。此选项是避免与进程相附接的保护机制。这意味着其他的进程不能够使用在其代码中此选项与该进程相附接。为了绕过此限制并且能够与进程相附接(即使其受PT_DENY_ATTACH选项保护也如此)，存在几种方案。

还可以使进程监视器与iOS中的应用进程相附接。用Objective-C(C的超集)来书写iOS中的应用。正如所有C程序一样，Objective-C程序以主要方法开始。自动针对iOS中的所有应用来创建此主要方法，并且该主要方法被置于支持文件组中的单独main.m文件中。所有应用具有相同的主要方法。每个主要方法呼叫UIApplicationMain方法，其负责加载为正在被启动的应用特定的类。

为了使进程监视器与新进程相附接，安全系统被配置成修改在运行iOS的设备上安装的每个应用的主要方法。具体地，安全系统被配置成首先修改iOS来启动安全系统的主要监视器，并且然后主要监视器将使用UIApplicationMain来启动每个应用。使主要方法代码的修改自动化。安全系统设置有通过应用来部署安全系统的脚本，并且该脚本使得修改所有main.m文件。另外地，脚本被配置成在安装了安全系统之后修改下载到设备上的任何应用的main.m文件。

main.m文件是编译代码，并且存在可以按照其用修改版本来修改或者置换main.m文件的各种方式。可选地，安全系统可以被配置成使用otool来修补应用的可执行体以反汇编二进制main.m代码，并且然后用所需ARM代码来对其进行修补以将呼叫插入到安全系统的主要监视代码。

当安装安全系统使得进程监视器能够与应用相附接并且监视应用时，可以使用后期安全策略绑定机制来使一个或更多个安全策略与应用相链接。iOS基于Unix，并且iOS使用其自身的/proc文件系统的版本。然而，为了访问在/proc文件系统中包含的应用识别数据或信息，可以使用sysctl特定系统呼叫。此系统呼叫检索关于内核状态的信息，包括运行进程的名称。使用sysctl系统呼叫，安全系统可以等待直到进程名称被设定为止(到这时，sysctl将能够检索该进程名称)，并且可以将安全策略加载或链接至进程。

通常基于Unix的系统

通常，后期安全策略绑定机制可以应用于任何基于Unix的系统(包括如上指出的Android、Linux和iOS)，在该基于Unix的系统中，创建新进程，并且在能够通过附接或嵌入在进程中的进程监视器直接地(关于例如Android和Linux中的/proc)或者间接地(关于例如iOS中的sysctl)访问的单独位置中设定新进程的专用化应用包名称。这是因为，在基于Unix的系统中，当进程被启动时，从父进程分叉出该进程。例如，在Linux OS的情况下，存在称为init的特定进程，init负责通过命令壳来开始任何新进程。当在Linux中部署安全系统时，主要监视器可以与init相附接，并且无论何时分叉出新进程，都将附接新进程监视器。然后使用后期安全策略绑定机制来确定要与新进程相链接并且在所监视的进程上执行的安全策略。

进程专用化的示例

在Unix/Linux操作系统中，进程的创建404独立于其专用化408，如图12所示。借助于fork系统呼叫来执行进程的创建。当进程呼叫fork时，创建404是父进程的准确拷贝的子进程。两个进程将彼此独立地继续执行。然而，每个进程必须知道其是子进程还是父进程。这可以通过由fork返回的值来进行。在父进程中，fork返回新创建子进程的进程ID(PID)。在子进程中，fork返回0。由于PID没有分配给任何进程，所以子进程知道其是子进程并且其必须进行专用化。

在Android中，以与Unix/Linux相似的方式来创建进程。然而，进程专用化的方式不同。在Unix/Linux中，子进程借助于呼叫来自exec系列的系统呼叫之一来进行专用化。当进程呼叫exec系统呼叫时，进程终止执行其当前程序并且从新程序的开头开始执行新程序。exec系统呼叫使用要被传递至程序的程序名称和参数作为变元。存在几种方式，其中子进程以这些方式得到要执行或者为专用为的程序的应用名称，如以下所进一步说明。

检索硬编码至父进程中的应用名称

在一个示例中，程序名称已经被硬编码在父进程代码中。在分叉出新子进程之后，子进程将使用该名称以用于通过execvp系统呼叫来执行该子进程。在此示例中，可以在分叉之后直接地从子进程代码中提取应用识别数据。

从文件检索应用名称

在另一示例中，父进程还可以从其代码外部检索程序名称。例如，父进程可以从文件读取程序名称。在此示例中，可以直接地从这种文件中提取应用识别数据。

从与父进程进行通信的外部进程检索应用名称

在另一示例中，父进程可以使用进程间通信(IPC)通道比如像Unix套接字的套接字来从外部进程检索命令。在此情况下，在分叉的父进程分支中打开客户端套接字。当父代通过套接字接收程序名称，父代分叉出子进程。当分叉时，程序名称将被包含在子存储器中，这是因为其仍是父进程的拷贝。

检索由外部进程推送至子进程的应用名称

在另一示例中，子进程可以被配置成打开IPC通道并且等待要通过该IPC通道提供的程序名称。仅通过示例，子进程可以使用套接字来收听程序名称。在此示例中，程序名称被推送至子代。在此情况下，在fork的子分支中打开客户端套接字。

检索由子进程从另一进程拉出的应用名称

在另一示例中，子进程可以被配置成建立与另一进程的IPC通道。在此示例中，子进程可以被配置成发送用于从其他进程拉出程序名称的请求。在此情况下，将在fork的子分支中打开客户端套接字。

Android—应用名称检索

在Android中，应用通常是编译成在Dalvik虚拟机中执行的字节代码的Java程序，并且可选地可以通过Java本机接口(JNI)来执行置于共享对象中的本机代码。Zygote进程是可以创建新应用的唯一进程。Zygote从内部Unix套接字接收分叉新应用的命令。命令包含将使用Java反射来加载进子进程的虚拟机中的Java类名称的名称。该类提供要被运行的应用的静态主要方法。然而，类名称不表示应用的包名称。将从应用的清单文件检索此信息，并且然后使用prctl系统呼叫来将此信息设定在/proc文件系统中，如先前所说明。

在进程执行期间链接安全策略

各种示例证明了可以如何使用后期安全策略绑定机制在新进程的分叉之后并且在进程专用为应用期间使应用特有安全策略与新启动进程相链接。

在其他的形式下，后期安全策略绑定机制可以延迟链接安全策略，直到进程已专用化之后并且当进程正在执行应用代码时为止。在此示例中，后期安全策略绑定机制被配置成：监视应用代码的执行，表征正在执行的应用的类型，并且链接适于所确定的应用类型的一个或更多个安全策略。通过示例，安全系统可以基于包括但不限于下述动作的各种进程动作来表征应用的类型：

●进程正试图访问什么硬件资源，例如，相机、网络、存储装置、存储器、GPS传感器、麦克风。

●进程正试图访问和/或修改哪种数据，例如，SMS、邮件、账号信息、图片、视频、口令。

●进程正试图与哪些其他的进程进行通信：访问设备中的其他应用、请求对敏感服务比如拨号器或SMS发送服务的访问。

安全系统可以阻止进程执行任何禁止动作，直到表征完成并且安全策略被链接为止。当安全策略与其进程监视器相链接时，允许进程继续正常执行至其进程监视器基于安全策略允许的程度。

5.第三实施例安全系统—虚拟化以提供隔离的用户空间实例

概述

参照图13至图15，提供了安全系统第三实施例，其适于提供光虚拟化机制，其在相同的OS和设备内提供多个隔离的用户空间实例或域。光虚拟化机制使用前述实施例中描述的SCI机制和FCI机制中的任一者或二者，以用于拦截函数呼叫和/或系统呼叫，并且根据表示当前在设备上操作的指定的或选择的用户空间实例(比如域或用户配置文件)的一个或更多个控制参数(在本文中为用户空间控制参数)来产生关于函数呼叫或系统呼叫的安全决定/动作。例如，控制参数定义要应用于所拦截的函数呼叫或系统呼叫的安全策略。系统被配置成使得相对于如通过控制参数指示的特定用户空间实例比如域来监视并且执行每个进程。通过控制参数指示的域将约束给定进程将如何与其他进程进行交互并且访问资源。

系统配置

参照图13，将描述适于提供虚拟化的第三实施例安全系统500的功能和主要组件的示例。如在前述实施例中所说明，OS层504中的进程502(对应于应用层中的应用)通过执行受OS支持的系统呼叫来与其他的进程进行交互，并且访问设备(比如文件系统516)中的资源。进程502首先在用户模式508下执行如通过函数呼叫506示出的对库(比如libc)函数的调用。通常，然后通过共享库(未示出)将函数呼叫506映射成在内核模式510下执行的系统呼叫512。然而，在此实施例中，正如前述实施例一样，通过呼叫拦截器514来检测并且拦截函数呼叫506和/或系统呼叫512。呼叫拦截器514被配置成使用先前描述的SCI机制和/或FCI机制来拦截函数呼叫和/或系统呼叫。例如，呼叫拦截器可以被配置成通过将特定函数挂钩注入在进程ELF中(即，先前描述的FCI机制)来拦截函数呼叫并且借助于ptrace(即，先前描述的SCI机制)来拦截系统呼叫。

当拦截呼叫506、512时，呼叫拦截器514将呼叫信息转发至与每个进程相附接和/或嵌入在每个进程内的监视实体512。然后，监视实体将基于定义特定用户空间操作的用户空间控制参数或变量519来检索应用于呼叫的适当安全策略。然后，监视实体将基于该检索的安全策略以与前述方式相同的方式来实现安全动作，比如，允许呼叫、拒绝呼叫、终止进程、或者修改呼叫的参数和/或呼叫的返回值。通过基于定义正在操作的用户空间的用户空间控制参数来配置监视实体以选择要应用的安全策略而在此修改的安全系统中提供虚拟化。另外地，策略数据库中提供的安全策略被扩展成满足可以在设备上操作的多个不同用户空间实例，如将在下面所更详细地说明。

在此配置下，安全系统能够根据哪个用户空间实例正在操作而将不同的安全策略动态地应用于应用，以从而控制与应用相对应的进程执行其操作并且访问设备资源的方式。此虚拟化机制实现细粒隔离，这是因为此虚拟化机制能够约束特定进程执行而无需控制整个OS。当每个进程没有意识到呼叫拦截器时，不需要修改进程或OS。另外地，此虚拟化机制不需要策略硬编码在系统中，并且因此可以动态地改变策略。

策略数据库

正如先前实施例一样，提供了包括被监视实体应用/执行的安全策略的策略数据库。策略数据库可以采用例如定义策略的一个或更多个策略配置文件的形式。所提供的策略可以包括：应用特有策略，一个应用特有策略用于每个用户空间实例或者用户空间实例的系列或子集合；和/或适用于所有应用或应用子集合的全局策略，一个全局策略用于每个用户空间实例或者用户空间实例的系列或子集合。

安全策略控制哪些进程可以彼此通信，进程可以如何利用/访问设备资源、数据或文件、或者其他的通用应用/进程权限和许可，进程可以基于该权限和许可在用户空间中操作。

用户空间控制参数

用户空间控制参数定义在设备上操作的用户空间实例。用户空间控制参数的性质取决于所提供或用户可用的不同用户空间实例的数目。在一个示例中，安全系统可以提供两个用户空间实例，即私人域与工作域，或者标准用户与客户端用户，并且控制参数定义哪个域已被激活，并且因此定义哪些安全策略应用于通过操作的进程产生的所拦截的呼叫。在另一示例中，安全系统可以提供多个用户空间实例，一个用户空间实例用于登录设备的每个不同用户或用户配置文件，并且这些用户空间实例中的每个用户空间实例可以进一步具有特定私人域与工作域。

可以由设备的用户经由系统配置设定或者由系统管理员手动地设定用户空间控制参数，或者可以由安全系统基于登录到设备的用户来自动地设定用户空间控制参数，或者可以另外通过与设备进行通信的远程第三方系统来设定用户空间控制参数。

由监视实体采取的安全动作

针对所检测的函数呼叫和/或系统呼叫，与每个进程相关联的监视实体被配置成基于针对用户空间实例来配置的安全策略来执行安全动作，用户空间实例如通过用户空间控制参数所确定来操作。所采取的安全动作可以基于下述策略：应用于至少调用呼叫的进程的全局策略、与进程相关联的应用特有策略、或者这些策略的组合。如果提供了相冲突的策略，则监视实体可以被配置成基于安全系统设定使全局策略优先于应用特定策略来解决冲突，或者反之亦然。

示例性情形

将通过参照图13至图15的进一步说明来描述针对光虚拟化而配置的安全系统的示例性配置。

在此示例中，安全系统被配置成支持两种单独用户空间，即，工作域(WD，WorkDomain)和私人域(PD，Private Domain)。WD指定允许执行企业批准进程并且访问敏感商业数据的安全策略。PD允许执行与设备用户的私人范围相关的进程。

设备上的每个应用/进程可能在两个域中可操作。因此，安全系统被配置成提供虚拟化提取，该虚拟化提取允许这种应用/进程执行，但是根据哪个域执行应用/进程而使用不同的权限。例如，进程中之一可能是Skype应用。在WD中针对Skype配置的安全策略将不同于针对PD而配置的安全策略。例如，当在WD中执行Skype时，Skype应当向用户提供与工作相关的联系人。而且，如果用户想要通过Skype发送商业数据，则应用将有权限来访问敏感数据。另一方面，当在PD下执行Skype时，应用应当仅提供与工作环境不相关的联系人。而且，应用不应当允许用户通过聊天来发送敏感数据。

为了能够支持此情形，安全系统被配置成使安全策略的执行有区别，该安全策略在不同的安全域下应用于同一应用。实现FCI机制和SCI机制中任一者或二者的呼叫拦截器514允许非常细粒级的实现，以能够区别对资源的访问。安全系统被配置成在由OS提供的应用的顶部向应用提供虚拟化系统呼叫集合。可以使用FCI机制或者SCI机制来实现这种虚拟化机制。

通过示例，将描述安全系统用于控制联系人列表的操作，Skype能够根据正在其中操作Skype的域来访问该联系人列表。设备设置有其中存储Skype联系人的多个文件(一个文件针对每个域)。针对WD的联系人列表文件存储在/data/data/WD/skype/contact.ast中。针对PD的联系人列表存储在/data/data/PD/skype/contact.ast中。这允许系统在应用特定文件之间独立。当Skype执行读取系统呼叫时，应用意识不到多个联系人文件的存在。该应用将试图在是/data/data/app/skype/contact.ast的所使用的标准目录上打开。然而，如将在以下使用FCI或SCI的呼叫虚拟化机制来进一步说明的，安全系统被配置成拦截此系统呼叫，并且根据哪个域是激活的(WD还是PD)，与Skype相关联的监视实体可以改变呼叫中参数来指向正确联系人列表文件。

如果我们现在假定在WD中部署粗糙应用。此粗糙应用试图访问cotanct.ast文件并且将此cotanct.ast文件发送至恶意服务器。安全系统可以基于针对WD的全局安全策略来执行安全策略以阻止粗糙应用建立与恶意服务器的连接，该全局安全策略指定：仅允许WD中的所有应用连接至一个列表中的公知服务器。

通过FCI呼叫虚拟化

为了虚拟化呼叫，安全系统可以使用函数呼叫插入(FCI)，以在函数呼叫被转换成由内核执行的系统呼叫之前拦截函数呼叫，并且实现任何分配的安全动作。安全系统被配置成使用GOT/PLT间接机制并且插入挂钩代理偏移表(POT，hook proxy offset table)，该挂钩代理偏移表(POT)与相对于图9B描述的POT类似。图14提供FCI如何用于虚拟化函数呼叫的示例，以及与相对于图9B的部件类似的附图标记。在此特定示例中，FCI机制用来虚拟化称为func的函数。此函数采用一个参数parl并且返回整数。GOT 334内部的函数指向345POT 340中的挂钩函数520。当POT 340中的挂钩函数520被执行时，挂钩函数520会使用PEP的方法enter来将参数parl转发至监视实体310中的PEP 339。参数parl作为参考来进行传递，意味着监视实体310中的PEP 339可以直接地修改其值。当参数的值被修改时，如果需要，则使用修改的参数524来呼叫原始函数。通过方法exit 526将通过函数执行返回的值提供至监视实体中的PEP339。而且，在此情况下，返回值作为参考来进行传递。然后，PEP 339还可以修改返回值，并且然后将修改的值返回至呼叫进程。借助于在监视实体中执行的安全策略来控制对函数参数和返回值的实际修改。如先前论述的，所应用的安全策略取决于用户空间控制参数，该用户空间控制参数定义进程正在其中操作的用户空间(例如，域)。

通过SCI的呼叫虚拟化

为了虚拟化呼叫，安全系统可以可替代地或者附加地在内核模式下使用系统呼叫插入(SCI，system call interposition)来拦截系统呼叫。在此情况下，安全系统可以使用如先前关于SCI机制描述的系统呼叫ptrace。另一方法可以修改OS来拦截所有系统呼叫。在下面示例中，在使用工具比如ptrace的环境中描述系统操作。如先前所描述的，在这种工具下，当内核即将代表进程执行系统呼叫时，内核将通知与进程相关联的监视实体两次：在实际上执行系统呼叫之前(在进入时)，和在执行了系统呼叫之后但在向呼叫进程提供返回值之前(在退出时)。

图15示出了使用SCI时系统呼叫func的虚拟化的消息序列图。当进程550请求551执行系统呼叫时，内核552停止553系统呼叫的执行并且通知555监视实体556。监视实体556从进程存储器检索557系统呼叫的参数的值。监视实体556然后可以根据要被执行的安全策略来修改558该值。此后，会将参数的值重新插入559进程存储器中。这时，准备执行系统呼叫，并且监视实体556通知560内核552让其运行。当内核552完成执行时但在内核将值返回至呼叫进程550之前，内核又通知561监视实体556。在此情况下，监视实体556检索返回值并且根据策略修改562该返回值。当返回值被修改时，该返回值被返回563至呼叫进程550。与通过FCI方法一样，借助于在监视实体中执行的安全策略来控制对系统呼叫参数和返回值的实际修改，并且所应用的安全策略取决于用户空间控制参数，该用户空间控制参数定义进程正在其中操作的用户空间(例如，域)。6.安全系统的设备硬件配置和安装

如上所阐述的，可以在运行Android OS或基于Linux的OS等的任何适合硬件设备或系统上实现安全系统的实施例。参照图16和图17，将描述安全系统可以在其上运行的典型智能电话或平板设备的硬件组件的示例，以及安全系统安装过程。

参照图16，通常，设备601比如智能电话或平板计算机包含以下组件：执行在永久存储设备603中和/或在易失性存储器603中存储的指令的处理器602。可以使用监视器/显示器/触摸屏606来显示从处理器输出的图像、视频和其他的多媒体。通过可以嵌入处理器602中的图形设备/触摸屏控制器605来准备用于显示器606的显示数据。用户可以通过触摸屏605或按钮609来操作设备。可以可选地通过控制器设备605来向处理器602反馈这种指令。可以通过扬声器608来输出声音，可以向该扬声器608通过I/O接口610提供信号，该I/O接口610可以嵌入处理器602中。可选地，触摸屏606可以向用户提供通过I/O接口610控制的触觉反馈。可选地，使设备通过由I/O接口610控制的振动/轰鸣设备620进行振动或者轰鸣以警告用户。设备可以配备有几个传感器以使用麦克风610记录声音并且使用相机611记录图像或视频。还可以存在位置(比如全球定位系统接收器)、加速度(加速度计)、方位(倾斜&陀螺仪)和环境(温度、光、辐射、湿度、气体、压力)传感器617。设备及其所有组件通过电池613来供电。可替代地，可以通过有线接口614来对设备进行供电。通过功率管理系统612来调节并且分配功率。可以通过有线接口614或者无线接口612来对电池进行充电。

为了与外界连接并且传送数据，设备可以使用有线连接614或者其他的(无线)连接615。(无线)连接615可以是基于无线电或光的通信。使用天线来发送并且接收用于无线通信的无线电信号616。此天线可以嵌入或可以不嵌入设备中。有线或无线连接可以提供联网能力。针对电信订阅信息，设备可以使用订户识别模块619，该订户识别模块619可以是插入设备中的卡。订户识别模块619可以通过控制器618与处理器602对接。

可以使用操作系统比如Android来使用户控制设备中的硬件和软件二者。操作系统是包括用于处理器602的指令集合的软件，该处理器602通常安装在永久存储设备603上。当设备正在操作时，操作系统还可以部分地置于易失性存储器604中。

恶意软件或代码(指令)可以由(无意识)用户或者另一方通过有线接口614或者无线连接615/616来置于设备存储位置603、604上。恶意软件或代码(指令)可以欺骗操作系统来使处理器602执行用于恶意目的的指令。为了防止处理器602执行恶意指令，前述实施例中描述的安全系统被安装在设备上，并且将与操作系统进行交互。安全系统通常安装在设备存储位置603、604上。

参照图17，将描述如何将安全系统安装在存储设备603上的示例。通常，具有所安装的操作系统(OS)比如Android的存储设备603包含下面分区：引导702、系统703、恢复704、数据705、缓存706和杂项(misc.)707。

第一实施例安全系统安装

为了使用第一实施例来部署安全系统，应当修改下面的模块。应当将主要监视器二进制置于设备的引导702分区中。而且，应当修改作为引导702分区的一部分的init.rc文件708以便于修改“zygote”服务，该“zygote”服务应当指向监视器二进制位置。为了修改设备的原始引导702分区，应当从设备拉出分区图像。在第二阶段中，应当拆开二进制文件，得到内核图像和引导加载器图像。然后应当通过将主要监视器二进制拷贝到引导加载器图像中(通常在/sbin文件夹中)并且修改init.rc 708文件来对引导加载器图像进行修补以更新“zygote”服务。引导加载器一旦被修补可以连同内核图像一起来重新包裹引导加载器以生成引导702分区的修补版本，其应当被推送回到物理设备中。

应当将安全系统置于系统703分区中。为此，应当使用书写许可来重新安装系统703分区，使得可以将服务包文件拷贝到系统703分区中(通常/system/app中)。分区一旦被拷贝可以将分区重新安装回其只读状态。可选地，监视器二进制还可以安装在系统703分区内(通常/system/bin内)。可选地，安全系统和/或本地策略配置文件(或策略数据库)的备份可以存储在恢复分区704中。在安装本地策略配置文件(或策略数据库)的情况下，该本地策略配置文件将连同安全系统可能需要使用的任何其他的数据文件(这可以包括在OS实现之后使得重新启用框架的所有系统组件的拷贝)一起来置于数据705分区中(通常/data/system内)。

当已将所有组件部署到设备中时，应当重启设备以结束进程。当设备已重新引导时，安全系统建立并且运行。

第二实施例安全系统安装

为了使用第二实施例部署安全系统，应当修改下面的模块。应当修改作为引导702分区的一部分的init.rc文件708以便于修改“zygote”服务，该“zygote”服务环境应当被设定成使得LD_PRELOAD指向代理函数库位置。为了修改设备的原始引导702分区，应当从设备拉出分区图像。在第二阶段中，应当拆开二进制文件，得到内核图像和引导加载器图像。然后应当通过修改init.rc 708文件来对引导加载器图像进行修补以更新“zygote”服务。引导加载器一旦被修补可以连同内核图像一起来重新包裹引导加载器以生成引导702分区的修补版本，其应当被推送回到物理设备中。

应当将安全系统置于系统703分区中。为此，应当使用书写许可来重新安装系统703分区，使得可以将服务包文件拷贝到系统703分区中(通常/system/app中)。分区一旦被拷贝可以将分区重新安装回其只读状态。代理函数库还应当安装在系统703分区内(通常/system/bin内)。在安装本地策略配置文件(或策略数据库)的情况下，该本地策略配置文件将连同安全系统可能需要使用的任何其他的数据文件(这可以包括在OS实现之后使得重新启用框架的所有系统组件的拷贝)一起来置于数据705分区中(通常/data/system内)。可选地，可以在恢复分区704中存储安全系统和/或本地策略配置文件(或策略数据库)的备份。当已将所有组件部署到设备中时，应当重启设备以结束进程。当设备已重新引导时，安全系统建立并且运行。

7.第四实施例安全系统—Google Chrome OS

以上安全系统的实施例还可以适于/适用于基于Linux的其他操作系统，比如，Google Chrome操作系统(OS)。Chromium项目包括作为在Google Chrome浏览器后面的开放源项目的Chromium；以及作为在Google Chrome OS后面的开放源项目的Chromium OS。

两个项目使其代码库的大部分是公共的。具体地，OS/Google Chrome OS是单独执行基于网页的应用的基于Linux的操作系统。此OS采用最低要求的方法，在该方法中，仅驻存在设备中的应用是浏览器(其是Google Chrome)、媒体播放器和文件系统。基本上，在浏览器内执行基于网页的应用。考虑(基本上在浏览器内运行应用)的常用方法，在下面论述中我们将使用术语Chromium来指两个项目(Chromium和Chromium OS)。

Chromium后面的主要思想是在不同进程中运行功能的实例。关于功能，这里我们指被下载以用于访问网页和执行网页应用的代码、以及将通过Chromium进程来渲染并且执行的其他代码。

如图18所示，Chromium具有负责显示用户接口(UI)并且管理其中执行选项卡和插件的其他进程802的主要进程800(称为“浏览器”801)。选项卡进程称为“渲染”，并且负责使用渲染引擎比如WebKit and Blink来渲染每个选项卡内的功能。在此意义上，选项卡和插件定义用于运行Chrome OS的设备的功能。

通过默认方式，Chromium针对用户访问的网站的每个实例(进程每站实例)创建新渲染器进程802。站被定义为注册域，比如auckland.ac.nz。这意味着，将在不同进程中执行指向相同站的多个选项卡。另一模型是进程每站(process-per-site)，在该进程每站中，将在不同进程中运行不同站。然而，将通过相同进程来运行指向相同站的多个选项卡。进程每选项卡是其中通过专用进程来渲染每个选项卡的另一模型。最后，可以在单个进程中执行Chromium。

图18示出了针对每个功能实例的不同渲染器进程的情况。具体地，在专用渲染器进程802内执行的每个选项卡803正向用户提供特定功能。例如，选项卡1使auckland.ac.nz网页可视化，选项卡2使facebook.com网页可视化，并且使选项卡3执行基于网页的应用。

每个渲染器进程802执行代码以向用户提供某些功能。此功能可以正在加载HTML页面或者正在执行基于网页的应用。从OS角度看，每个进程802是主要进程800(浏览器)的子代，并且意识不到由每个渲染器进程提供的特定功能。然而，OS不直接查看每个渲染器进程的功能。换句话说，每个渲染器进程是“不透明”进程。因此，执行为每个渲染器进程的功能特定的安全策略不是直观的。

通过使渲染器执行下述动作来执行将特定功能加载在每个渲染器进程802内：使主要进程800通过进程间通信(IPC)呼叫805来从网页取得代码。使用由内核提供的接口借助于函数呼叫和系统呼叫来建立主要进程800与所有渲染器802之间的IPC通道。例如，当在Linux和Mac OS X上部署Chromium时使用socketpair()函数/系统呼叫以建立主要进程800与渲染器进程802之间的通道。可以部署前述实施例中描述的安全系统以利用此通信通道来拦截指示在每个渲染器进程中加载的功能的消息并且执行特定安全策略，如接下来将说明的。

图19示出了可以如何将安全系统监视器或监视实体与Chromium内的不同进程相附接。首先，主要监视器810将与主要进程800相附接或者主要监视器810将嵌入在主要进程800内，并且主要监视器810将监视其何时将分裂出新渲染器进程802。当新渲染器进程802被分裂出时，新进程监视器812(或监视实体)将与新子进程802相附接，使得每个新进程具有其自己相应的监视实体。Chromium使用与Android中相同的方法以使用Zygote进程来分裂出新进程，该Zygote进程将使自己分叉以创建渲染器进程。

每个监视实体812可以拦截其关联渲染器进程802产生的系统呼叫以与主要进程800进行通信并且提取用于识别每个渲染器正在执行哪个功能的信息。这允许安全系统将定制的(来自策略数据库的)特定安全策略与每个渲染器将执行的功能相关联，即，每个监视实体检索并且执行与应用的进程相对应的应用的安全策略。比如，监视渲染器进程1的监视实体812将执行为域Auckland.ac.nz(选项卡1)特定的安全策略，然而，监视渲染器进程2的监视实体812将执行为域Facebook.com(选项卡2)特定的策略。将理解的是，主要监视器800和进程监视器802可以是它们正在监视的相应进程的任一部分(例如，嵌入在该相应进程内)，在这种情况下使用FCI技术；或者是附接至它们正在监视的相应进程的独立进程，在这种情况下使用SCI技术，先前实施例中描述了这两种技术。

8.示例

下面阐述一些实施例的各种示例性配置和/或方法。

第一示例是用于使在设备上运行的操作系统安全的方法，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义。该方法包括：监视由Linux层中的母进程进行的向内核的系统呼叫，以检测Linux层中与应用层中的新应用或部分应用相对应的新进程的启动。该方法还包括：在由母进程创建了Linux层中的新监视进程时，使该新监视进程与新启动进程相附接，该监视进程被配置成监视由新进程进行的向内核的系统呼叫，并且该监视进程被配置成基于所检测到的系统呼叫的参数来检索并且执行为新进程配置的安全策略。

第二示例是用于在设备上运行的操作系统的安全系统，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义。该系统包括：在Linux层处运行的主监视进程，该主监视进程被配置成检测由母进程在Linux层中对新进程的启动，该新进程对应于由设备的用户对在应用层中对新应用或部分应用的启动。系统还提供进程监视器，该进程监视器由主监视进程与由母进程创建的每个新进程相附接，并且每个进程监视器被配置成监视由其附接的进程向内核进行的系统呼叫。还提供在应用层处运行的安全系统服务，该安全系统服务能够操作成访问所存储的针对应用层的应用的可配置安全策略，并且该安全系统服务能够与Linux层中的每个进程监视器进行通信，该安全策略对应于进程监视器的相附接的进程，并且其中，每个进程监视器被配置成基于所检测到的系统呼叫的参数来检索并且执行针对该进程监视器的相附接的进程而配置的安全策略。

第三示例是在安全系统中配置与新目标进程相附接的进程监视器的方法，该安全系统用于在设备上运行的操作系统，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的较高应用层来定义。该方法包括：当目标进程专用为其预期应用时监视该目标进程的专用化进程；从专用化进程中提取应用识别数据，该专用化进程表示目标进程正专用为应用或应用类型；基于所提取的应用识别数据从策略数据库中检索为该目标进程特定的安全策略；以及配置进程监视器以执行所检索到的安全策略。

第四示例是在安全系统中使存储在策略数据库中的安全策略与Linux层中启动的对应新进程相链接的方法，该安全策略是为应用层中的应用所特定的，该安全系统用于在设备上运行的操作系统，该操作系统包括基于Linux的内核。操作系统具有系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义。该方法包括：当新进程专用为其预期的应用时监视该新进程的在Linux层的专用化进程；从表示目标进程正专用为应用或应用类型的专用化进程提取应用识别数据；以及基于应用识别数据来创建新进程与来自策略数据库的安全策略之间的链接。

第五示例是在Linux层实现安全策略的方法，针对应用层中的应用或应用类型来定义该策略，其中，该方法包括：监视对被新Linux进程用于专用为其预期的应用的代码的加载和/或识别。该方法还包括：基于所加载或识别的代码将用于在Linux层实现的一个或更多个安全策略与新Linux进程相链接。

第六示例是使在设备上运行的操作系统安全的方法，该操作系统包括在Linux层中的基于Linux的内核，系统架构包括在该Linux层以上的应用层中的应用。该方法包括：将监视实体嵌入Linux层中的与应用层中的新应用或应用组件相对应的每个新启动进程内；配置每个新启动进程，以将该新启动进程的共享的或动态的库符号调用重定向至该进程内所嵌入的监视实体；配置每个所嵌入的监视实体，以分析由该监视实体的相关联的进程进行的重定向符号调用并且基于与该进程相关联的安全策略来执行安全动作。

第七示例是使在设备上运行的操作系统安全的方法，该操作系统包括在Linux层中的基于Linux的内核，系统架构包括在该Linux层以上的应用层中的应用。该方法包括：拦截由进程进行的意图调用内核中的系统呼叫的共享的或动态的库符号调用；以及基于为应用配置的安全策略，针对所拦截的符号调用来发起安全动作，所述应用与呼叫所拦截的符号调用的进程相对应。

第八示例是用于在设备上运行的操作系统的安全系统，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义。该系统包括：在Linux层中的每个启动进程内的嵌入监视实体，每个启动进程对应于应用层中的应用。该系统还包括与每个进程相关联的拦截器，该拦截器被配置成拦截由该拦截器的相关联的进程进行的共享的或动态的库符号调用中的至少一些库符号调用，并且被配置成将这些库符号调用重定向至发起符号调用的进程内所嵌入的监视实体。所嵌入的监视实体被配置成分析所拦截的由该监视实体的相关联的进程进行的符号调用，并且被配置成基于与该进程相关联的安全策略来执行安全动作。

第九示例是用于使在设备上运行的操作系统安全的方法，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义。该方法包括：创建对由母进程调用的系统呼叫和/或库函数呼叫进行监视的监视实体，以检测将与应用层中新应用相对应的新进程的创建；以及当母进程创建新启动进程时创建对该新启动进程进行监视的新监视实体，该新监视实体被配置成检测由新进程进行的系统呼叫和/或库函数呼叫，并且被配置成基于所检测到的系统呼叫和/或库函数呼叫的参数来检索并且执行为新进程配置的安全策略。

第十示例是用于使在设备上运行的操作系统安全的方法，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义。该方法包括：创建对由母进程调用的系统呼叫进行直接地或间接地监视的监视实体，以检测将与应用层中新应用相对应的新进程的创建；以及当母进程创建新启动进程时创建对该新启动进程进行监视的新监视实体，该新监视实体被配置成直接地或间接地检测由新进程进行的系统呼叫调用，并且被配置成基于所检测到的系统呼叫调用的参数来检索并且执行为新进程配置的安全策略。

第十一示例是使在设备上运行的操作系统安全的方法，该操作系统包括在Linux层中的基于Linux的内核，系统架构包括在该Linux层以上的应用层中的应用。该方法包括：使用第一监视机制来检测由进程进行的共享的或动态的库符号调用，并且基于与调用该符号调用的相应进程相关联的安全策略，针对所检测到的符号调用来发起安全动作；检测试图执行预定义的高风险动作集合中的一个高风险动作的高风险进程；以及发起第二监视机制来监视由所检测到的高风险进程所调用的系统呼叫。

第十二示例是使在设备上运行的操作系统安全的方法，该操作系统包括在Linux层中的基于Linux的内核，系统架构包括在该Linux层以上的应用层中的应用。该方法包括：发起被配置成对由进程进行的至少一些共享的或动态的库符号调用进行检测的一次监视机制，并且基于与调用所检测到的符号调用的进程相关联的安全策略，针对所检测到的符号调用来执行安全动作；检测试图执行预定义的高风险动作集合中的一个高风险动作的高风险进程，并且切换成二次监视机制来检测由所检测到的高风险进程所调用的系统呼叫；以及基于与调用所检测到的系统呼叫的所检测到的高风险进程相关联的安全策略，针对每个所检测到的系统呼叫来执行安全动作。

第十三示例是使一个或更多个应用特定安全策略与在设备的操作系统中启动的新进程相链接的方法。该设备具有：操作系统，该操作系统能够操作成运行进程；以及中间件，该中间件能够操作成通过从现有进程或母进程分裂或分叉出新进程来使该操作系统启动新进程，并且能够操作成使用为应用所特定的代码来使新进程专用为运行应用。所述方法包括：检测新进程；在检测到新进程之后监视预定义事件或预定义识别阈值；以及在检测到预定义事件或达到预定义识别阈值时使一个或更多个安全策略与新进程相链接。

第十四示例是使一个或更多个应用特有安全策略与操作系统中启动的新进程相链接的方法。该方法包括：检测新进程的启动；以及至少将一个或更多个安全策略与新进程的链接延迟至该新进程使用其应用特有代码开始进行专用化以用于执行为止。

第十五示例是一种设备，该设备包括运行进程的操作系统和能够操作成启动应用的中间件层，其中，使用操作系统中的一个或更多个进程来运行由中间件层启动的应用。该操作系统具有用户层和内核，其中，进程在操作系统的用户层中运行并且通过内核与在用户层中运行的其他进程进行交互，该交互响应于由进程进行的至内核的呼叫。该设备还包括：一个或更多个策略文件，该一个或更多个策略文件定义用于使进程与设备的内核交互的策略；以及监视器，该监视器被配置成监视进程与内核的交互以使所定义的策略与进程相链接或相关联，并且被配置成读取在与进程相链接或相关联的一个或更多个策略文件中定义的代码。

第十六示例是使设备上的操作系统虚拟化以提供能够在该设备上操作的多个隔离的用户空间实例的方法，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义。该方法包括：拦截由进程进行的系统呼叫和/或库函数呼叫，每个进程对应于应用层中的应用；以及至少基于用户空间控制参数和与进程相关联的安全策略，针对所拦截的系统呼叫和/或库函数呼叫来发起安全动作，该用户空间控制参数指示当前在该设备上操作的特定用户空间实例。

第十七示例是用于使在设备上运行的操作系统虚拟化以提供能够在该设备上操作的多个隔离的用户空间实例的虚拟化系统，该操作系统包括基于Linux的内核并且包括系统架构，该系统架构由与内核相关联的Linux层和包括应用的更高应用层来定义。该系统包括：与Linux层中每个启动进程相关联的监视实体，每个启动进程对应于应用层中的应用；以及与每个进程相关联的拦截器，该拦截器被配置成拦截系统呼叫和/或库函数呼叫，并且被配置成将系统呼叫和/或库函数呼叫重定向至与发起系统呼叫和/或库函数呼叫的进程相关联的监视实体。监视实体被配置成分析所拦截的由该监视实体的相关联的进程进行的系统呼叫和/或库函数呼叫，并且被配置成至少基于用户空间控制参数和与该进程相关联的安全策略来执行安全动作，该用户空间控制参数指示当前在设备上操作的特定用户空间实例。

第十八示例是一种设备，该设备包括一个或更多个资源，该一个或更多个资源包括处理器并且能够配置成以由该设备接收的功能代码定义的功能，该设备还包括操作系统，该操作系统包括用户层和内核，该用户层能够操作成运行进程，并且该内核能够操作成给该进程提供使用该设备的一个或更多个资源的接口。该设备存储启动器代码，该启动器代码能够操作成将所接收的功能代码作为新进程启动并且能够操作成使新进程根据该功能代码进行专用化，由此，在该新进程经由通过内核提供的接口来使用设备的资源的情况下，执行由该功能代码针对设备定义的功能。所述设备还存储策略代码，该策略代码定义用于所接收的每个功能代码或每个功能代码类型的策略，并且其中，设备包括监视代码，该监视代码能够操作成使策略代码实例与进程相关联并且能够操作成根据所关联的策略代码来监视进程。

第十九示例是使在系统上执行的应用的操作安全的方法，该系统包括linux层和中间件层，该中间件层能够操作成通过下述操作来启动应用：使linux层中的进程从其他的进程或者从母进程分裂，并且使linux层中的进程使用为该应用所特定的代码进行专用化。该方法包括：监视母进程或现有进程以检测分裂进程；监视分裂进程执行以便于识别哪个进程进行了专用化；以及监视由经专用化的进程进行的函数呼叫以确定相对于该函数呼叫执行的安全动作。

在一些实施例中，上述示例中的任意示例可以采用计算机可读介质的形式，该计算机可读介质上存储有计算机可读指令，该计算机可读指令在处理设备上被执行时，使该处理设备执行在前述示例中描述的方法中的任何一种或更多种方法，或者使该处理设备实现该示例中描述的系统中的任何一种或更多种系统。

在一些实施例中，上述示例中任意示例可以实现在具有处理器和存储器的设备或系统上，并且其中，该处理器被配置成或被编程为：实现或执行在示例中描述的方法中的任何一种或更多种方法，或者实现示例中描述的系统中的任何一种或更多种系统。

9.概要

安全系统的实施例可以通过硬件、软件、固件、中间件、微代码、或者其任意组合来实现。执行所需任务的程序代码或者代码段当在软件、固件、中间件或微代码中被实现时可以存储在机器可读介质比如存储介质或其他存储装置中。处理器可以执行所需任务。代码段可以表示过程、函数、子程序、程序、例程、子例程、模块、软件包、类、或者指令、数据结构或程序语句的任意组合。代码段可以通过传递和/或接收信息、数据、变元、参数或存储内容来耦接至另一代码段或者硬件电路。可以经由包括存储器共享、消息传递、令牌传递、网络传输等的任意适合手段来传递、转发或者传输信息、变元、参数、数据等。

在前文中，存储介质可以表示用于存储数据的一个或更多个设备，包括只读存储器(ROM)、随机访问存储器(RAM)、磁盘存储介质、光存储介质、快闪存储设备和/或用于存储信息的其他机器可读介质。术语“机器可读介质”和“计算机可读介质”包括但不限于便携式或固定式存储设备、光存储设备和/或能够存储、包含或载送指令和/或数据的各种其他介质。

使用被设计成执行本文所述功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他的可编程逻辑组件、离散门或晶体管逻辑、离散硬件组件、或者其任意组合可以实现或者执行结合本文中公开的示例来描述的各种例示性逻辑块、模块、电路、元件和/或组件。通用处理器可以是微处理器，但是在替换方案中，处理器可以是任何常规处理器、控制器、微控制器、电路和/或状态机。处理器还可以实现为计算组件的组合，例如，DSP和微处理器的组合、多个微处理器、与DSP核结合的一个活更多个微处理器、或者任何其他的这种配置。

结合本文中公开的示例来描述的方法或算法可以采用处理单元、编程指令或者其他的指示的形式来直接地实施为硬件、可由处理器执行的软件模块、或者这二者的组合，并且该方法或算法可以包含在单个设备中或者分布在多个设备中。软件模块可以驻存在RAM存储器、快闪存储器、ROM存储器、EPROM存储器、寄存器、硬盘、可移除盘、CD-ROM、或者现有技术中已知的任何其他形式的存储介质。存储介质可以与处理器耦接，使得处理器可以从存储介质读取信息并且向存储介质写入信息。在替换方案中，存储介质可以与处理器集成。

图中图示出的组件和函数中的一个或更多个可以在不偏离本公开的范围的情况下重新布置和/或组合成单个组件或者实施为几个组件。还可以在不偏离本公开的范围的情况下添加另外的元件或组件。另外地，本文中描述的特征可以以软件、硬件或者其组合来实现。

在其各个方面中，本文中各个实施例可以实现为计算机实现的进程、机器(比如，电子设备、通用计算机、或提供能够执行计算机程序的平台的其他设备)、由这些机器执行的进程、或者制品。这种成品可以包括：计算机程序产品或者数字信息产品，其中，计算机可读存储介质包含计算机程序指令或者计算机可读存储介质上存储由计算机可读数据；以及创建并且使用这些制品的进程和机器。

本主题的前述描述包括其各种形式。可以在不偏离本公开的范围的情况下对其进行修改。

Claims (28)

1.一种在运行于设备上的操作系统的安全系统中使被存储在策略数据库中并且特定于在应用层中的应用的安全策略与在更低层的用户模式下启动的相应的新进程相链接的方法，所述操作系统的架构包括内核和中间件层，所述内核能够在所述更低层的内核模式下操作，所述中间件层在与所述内核相关联的所述更低层与包括多个应用的更高的所述应用层之间，所述方法包括：

当所述新进程专用为其预期应用时，监视所述新进程的由所述操作系统在所述更低层的用户模式下执行的专用化进程，由所述操作系统执行的所述专用化进程包括识别与所述新进程相关的在所述应用层中的相应的应用并且将所述相应的应用的应用特定代码加载进所述进程用于执行；

从表示所述新进程正专用为所述应用或应用类型的所述专用化进程提取应用识别数据；以及

基于所述应用识别数据在所述新进程与来自所述策略数据库的安全策略之间创建链接。

2.根据权利要求1所述的方法，其中，创建链接包括从所述策略数据库检索所述安全策略并且将所述安全策略加载进被附接至所述新进程的用于执行所述安全策略的进程监视器。

3.一种在操作系统架构中实现安全策略的方法，所述操作系统架构包括更低层，所述更低层包括内核，所述更低层能够在内核模式和用户模式下操作，在所述更低层内，进程与在更高的应用层中的应用对应地执行，针对在更高的应用层中的应用或应用类型来定义所述安全策略，其中，所述方法包括：监视由操作系统在所述更低层的所述用户模式下执行的专用化进程；包括加载和/或识别用于专用化在所述更低层的用户模式下启动的新进程的代码，以实现所述新进程的相应预期应用；以及基于所加载或所识别的代码将用于在所述更低层的所述用户模式下实现的安全策略链接至所述新进程。

4.根据权利要求3所述的方法，其中，针对每个应用或应用类型来定义所述安全策略。

5.根据权利要求3或4所述的方法，其中，将安全策略链接至所述新进程包括根据用于专用化所述新进程的所述代码来识别用于所述新进程的安全策略。

6.一种在运行于设备上的操作系统的安全系统中配置附接至新目标进程的进程监视器的方法，所述操作系统的架构包括内核和中间件层，所述内核能够在更低层的内核模式下操作，所述中间件层在与所述内核相关联的所述更低层与包括多个应用的更高的应用层之间，所述方法包括：

当在所述更低层的用户模式下启动的所述目标进程专用为其预期应用时，监视所述目标进程的由所述操作系统在所述更低层的用户模式下执行的专用化进程，由所述操作系统执行的所述专用化进程包括识别与所述目标进程相关的在所述应用层中的相应的应用并且加载所述相应的应用的应用特定代码用于执行；

从表示所述目标进程正专用为所述应用或应用类型的所述专用化进程提取应用识别数据；

基于所提取的应用识别数据从策略数据库检索特定于所述目标进程的安全策略；以及

配置所述进程监视器以执行所检索的安全策略。

7.一种用于使在设备上运行的操作系统安全的方法，所述操作系统的架构包括内核和中间件层，所述内核能够在更低层的内核模式下操作，所述中间件层在与所述内核相关联的所述更低层与包括多个应用的更高的应用层之间，所述方法包括：

监视母进程在所述更低层中对所述内核模式的系统呼叫，以检测在所述更低层的用户模式下的新进程的启动，所述新进程对应于所述应用层中的新应用或应用的一部分；以及

一旦由所述母进程创建了所启动的新进程，使在所述更低层的用户模式下的新监视器进程附接至在所述更低层的用户模式下的新启动进程，所述监视器进程被配置成监视由所述新进程作出的对所述内核的系统呼叫，并且被配置成检索和执行基于所检测的系统呼叫的参数为所述新进程配置的安全策略。

8.根据权利要求7所述的方法，还包括为所述应用层中的应用提供在策略数据库中的安全策略。

9.根据权利要求7所述的方法，其中，将监视器进程附接至在所述更低层中的所述新进程包括将所述监视器进程配置为主机进程，并且将相关联的新进程配置为所述监视器进程的目标进程。

10.根据权利要求9所述的方法，其中，将所述监视器进程附接至所述新进程包括请求所述内核执行跟踪系统呼叫，所述跟踪系统呼叫被配置成拦截由所述目标进程执行的所有系统呼叫或至少一组系统呼叫并且在执行所述系统呼叫之前向所述主机进程报告所述系统呼叫。

11.根据权利要求10所述的方法，其中，所述跟踪系统呼叫是进程跟踪系统呼叫。

12.根据权利要求10或权利要求11所述的方法，其中，所述内核被配置成在执行所述系统呼叫之前和之后都向所述主机进程报告由所述目标进程作出的系统呼叫。

13.根据权利要求8所述的方法，其中，所述监视器进程被配置成从在所述应用层处的安全系统服务访问并且检索用于所述监视器进程的相附接新进程的安全策略，所述安全系统服务已访问了所述策略数据库中的用于所述应用层的应用的可配置安全策略。

14.根据权利要求13所述的方法，其中，所述更低层处的所述监视器进程被配置成与应用层处的所述安全系统服务建立通信链接。

15.根据权利要求9所述的方法，其中，所述方法还包括通过下述操作来向所述新监视器进程加载用于所述新监视器进程的相附接目标进程的相关安全策略：

当所述目标进程专用为其预期的应用时，监视所述目标进程的由所述操作系统在所述更低层的用户模式下执行的专用化进程，由所述操作系统执行的所述专用化进程包括识别与所述新进程相关的在所述应用层中的相应的应用并且加载所述相应的应用的应用特定代码用于执行；

从表示所述目标进程正专用为所述应用的所述专用化进程提取应用识别数据；以及

基于所提取的应用识别数据检索用于所述目标进程的所述相关安全策略。

16.根据权利要求15所述的方法，其中，所述应用识别数据可以是应用包名称。

17.根据权利要求15或权利要求16所述的方法，其中，所述方法包括在所述专用化进程中从系统呼叫提取应用识别数据。

18.根据权利要求15或权利要求16所述的方法，其中，所述方法包括从在所述专用化进程期间写入了所述目标进程的全应用包名称的专用化数据文件提取所述应用识别数据。

19.一种用于在设备上运行的操作系统的安全系统，所述操作系统的架构包括：更低层，所述更低层包括内核，所述更低层能够在内核模式和用户模式下操作，在所述更低层内，进程与在更高的应用层中的应用对应地执行；以及中间件层，所述中间件层在与所述内核相关联的所述更低层与包括多个应用的更高的所述应用层之间，所述系统包括：

主监视器进程，所述主监视器进程在所述更低层中的用户模式下运行，被配置成检测由母进程进行的在所述更低层中的用户模式下的新进程的启动，所述新进程对应于由所述设备的用户对在所述应用层中的新应用和应用的一部分的启动；

进程监视器，所述进程监视器由所述主监视器附接至由所述母进程创建的每个新进程，并且每个进程监视器还在所述更低层的用户模式下执行并且被配置成监视由所述进程监视器的相附接进程作出的对所述内核的系统呼叫；以及

安全系统服务，所述安全系统服务在所述应用层运行，能够访问所存储的用于所述应用层的应用的可配置安全策略，所述安全系统服务与在所述更低层中的每个进程监视器关于与所述每个进程监视器的相附接的进程对应的所述安全策略进行通信，并且其中，每个进程监视器被配置成基于所检测的系统呼叫的参数来检索并且执行为所述进程监视器的相附接的进程配置的安全策略。

20.根据权利要求19所述的安全系统，还包括可访问策略数据库，所述可访问策略数据库包括所存储的用于所述应用层中的应用的可配置安全策略。

21.根据权利要求20所述的安全系统，其中，所述策略数据库被存储在所述设备上，或者被远程地存储并且被所述设备访问。

22.根据权利要求19所述的安全系统，其中，所述主监视器进程被附接至所述母进程。

23.根据权利要求22所述的安全系统，其中，通过进程跟踪系统呼叫将所述主监视器进程附接至所述母进程，其中，所述主监视器被配置为主机进程并且所述母进程被配置为目标进程。

24.根据权利要求19-23中任意一项所述的安全系统，其中，通过进程跟踪系统呼叫将每个进程监视器附接至其相应的进程，其中，所述进程监视器是主机进程，并且所述进程监视器的相附接的相应进程是目标进程。

25.根据权利要求19-23中任意一项所述的安全系统，其中，每个进程监视器被配置成通过从所述安全系统服务检索安全策略来加载用于所述进程监视器的相附接的目标进程的安全策略。

26.根据权利要求25所述的安全系统，其中，每个进程监视器被配置成监视所述进程监视器的目标进程的由所述操作系统在所述更低层的所述用户模式下执行的专用化进程，以提取应用识别数据，所述应用识别数据表示所述目标进程正被专用为所述应用；以及被配置成基于所提取的应用识别数据从所述安全系统服务检索用于所述目标进程的相关安全策略。

27.根据权利要求19-23中任意一项所述的安全系统，其中，每个进程监视器被配置成通过在所述更低层与更高的所述应用层之间的通信机制与所述安全系统服务进行通信。

28.根据权利要求27所述的安全系统，其中，所述通信机制包括通过传输控制协议链接的客户端-服务器事务。