CN105094797A - 用于电子设备的应用分析系统 - Google Patents

Abstract

一种用于分析在目标设备上执行的应用的分析系统。这种系统包括在目标设备上运行的分析代理，该分析代理被配置为用于对指示在执行期间由多个应用所发起的多个系统调用的信息进行接收或检索。这种系统还包括通过数据通信链路与该目标设备进行数据通信的分析设备，该分析设备被配置为用于通过该数据通信链路从该目标设备的该分析代理接收信息。该分析设备包括被配置为用于显示所接收的信息以供用户观看和/或交互的分析图形用户界面(GUI)。

Description

用于电子设备的应用分析系统

技术领域

本说明书涉及一种用于分析和概要分析在电子设备操作系统(包括但不限于Linux或基于Linux的系统)上执行的应用的系统。具体地，但不是排他地，该分析系统适用于硬件设备和系统，如手机、智能电话、平板计算机以及其他便携式和桌面计算与通信设备。

背景技术

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

此中间件层包括一组共享库，该组共享库提供如数据存储、屏幕显示或多媒体等服务，并且被编译成机器语言以使得能够快速执行服务。这些中间件库实现了设备特定的功能，因此，应用和应用框架不需要顾虑安卓设备之间的变化。中间件层还支持特殊化的版本的Java运行时以简化跨平台开发。具体地，它提供了Dalvik虚拟机(DVM)以及其多个核Java应用库。可以将开发者所实现的应用或服务从Jave(或其他支持语言)编译成可以由DVM运行的字节码。

虽然中间件层简化了应用开发，它也显著增加了总体安卓操作系统的复杂度。此附加的复杂度可能会被编程以进行恶意任务(恶意软件)或执行恶意代码(malcode)的应用或服务利用。

举例来说，恶意软件或恶意代码可以利用进程间通信(IPC)或组件间通信(ICC)来攻击敏感的应用及其数据。参考图1，在对应的DVM14、16中执行每一个安卓应用10、12。在启动时，每一个应用对应于DVM的实例。将每一个DVM14、16映射到在Linux层24中的用户模式22下运行的专用进程18、20中。在安卓中，应用可以使用IPC机制来彼此通信。但是，在安卓中实现IPC的标准机制是Binder框架。Binder框架具有用于提供从一个进程到另一个进程的函数和数据的绑定的设施。在三个层级中提供安卓中的Binder框架。在应用层42，有应用编程接口(API)26、28以使得应用能够彼此进行通信。作为此API的一部分的安卓接口定义语言允许开发者针对安卓服务来定义接口，并且AIDL解析器生成服务客户端可以使用的Jave客户端代码以及开发者可以用来创建服务实现的服务桩(servicestub)。在本机中间件层44，使用C++语言实现的Binder类30提供了由这些应用通过Java本地接口(JNI)所使用的用户空间设施，并且与作为定制的Linux安卓内核的一部分的Binder内核驱动32交互。Binder内核驱动32进行进程间的消息传递，并且提供共享存储器设施。驱动位于特殊设备之后，/dev/binder，并且可以通过各种系统调用(如打开(open)和输入/输出控制(ioctl))来使用，以使得进程能够彼此进行通信。

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

在常规的Unix和Linux操作系统中，已经提出了形式为可以跟踪进程以强制执行安全策略的内核模块的安全系统(如SELinux或Linux安全模块)。这涉及到重新编译内核映像以便注册模块并且能够最终加载它。此外，在由用户通过外壳(shell)命令行来启动新的应用时，监视模块能够通过分析那些命令行实参将正确的安全策略链接至新启动的进程。此类安全系统在安卓上不能有效工作，安卓使用一种明显不同的启动和管理应用的方式。还令人期望的是，具有一种用于安卓的不要求重新编译Linux内核的安全系统。

针对布置在多个设备上的安全系统设置安全策略的管理员可能需要对在运行时执行的多个应用进行分析或概要分析，以标识恶意或可疑行为。运行操作系统(如Linux)的某些设备要求特殊化的内核层模块(如审计(Audit)系统)以支持这种分析。然而，安卓中存在的内核(当是基于Linux的内核时)经常是台式计算机版本的简化版，并且如Audit等的内核模块并不默认存在。

管理员可以使用调试器来分析应用。然而，调试器依赖于有待使用被使能能够采集有意义信息的特殊标记来进行编译的库。出于性能原因，设备上所采用的这些库默认禁用调试符号。为使能这些调试符号，用户必须使用编译特殊标记对这些库进行重新编译，并且在设备内对它们进行重新部署。

在本说明书中，引用了专利说明书、其他外部文件、或其他信息源，这通常是出于为讨论各实施例的特征提供上下文的目的。除非另有具体说明，引用这种外部文件在任何司法权下不应被解释为承认这种文件或这种信息源是现有技术或者形成本领域中公知常识的一部分。

发明内容

至少某些实施例的目的是提供一种用于分析和/或概要分析在设备的操作系统上执行的应用的系统，或者至少向公众提供一种有用的选择。

至少某些实施例的目的是提供一种用于对由安全系统对在设备的操作系统上执行的应用强制执行的一个或多个安全策略的性能进行分析的系统，或者至少向公众提供一种有用的选择。

在第一方面，本发明广泛地包括一种用于分析在目标设备上执行的应用的分析系统，该系统包括：

在该目标设备上运行的分析代理，该分析代理被配置为用于对指示在执行期间由多个应用所发起的多个系统调用的信息进行接收或检索；以及

通过数据通信链路与该目标设备进行数据通信的分析设备，该分析设备被配置为用于通过该数据通信链路从该目标设备的分析代理接收该信息，并且其中，该分析设备包括被配置为用于显示所接收的该信息以供用户观看和/或交互的分析图形用户界面(GUI)。

在实施例中，该目标设备进一步包括与每一个执行应用相关联的监视实体，每一个监视实体被配置为用于直接或间接地检测由其相关联的应用所进行的系统调用。在一种形式下，这些监视实体通过拦截对该目标设备的操作系统的内核的系统调用来直接监视或者检测系统调用。在另一种形式下，这些监视实体通过拦截共享或动态库符号调用来间接监视或检测多个系统调用，这些共享或动态库符号调用旨在调用对内核的一个或多个系统调用。

在实施例中，这些监视实体将所检测到的这些系统调用直接或间接地转发至该分析代理。在一个实施例中，每一个监视实体包括相关联的概要分析器，该概要分析器被配置为用于对指示这些系统调用的信息进行检索或接收，这些系统调用由该概要分析器的相关联的监视实体所检测并且将该信息转发至该分析代理。

在某些实施例中，这些概要分析器被配置为用于通过进程间通信(IPC)通道向该分析代理发送信息。

在实施例中，这些监视实体被配置为用于在检测到系统调用时停止或暂停应用的执行，并且等待用于强制执行的安全决策，该安全决策是关于如何处理所检测到的该系统调用的执行的指令。举例来说，在一个实施例中，该安全决策可以是以下各项中的任何一项：允许执行该系统调用、拒绝执行该系统调用、修改该系统调用、或完全取消该应用执行。

在某些实施例中，该分析系统在多种模式中的所选择的一种模式下是可操作的。在某些配置下，所选择的模式确定如何将这些监视实体配置为用于针对每一个所检测到的系统调用确定用于强制执行的安全决策。

在分析系统的一种操作模式下(如，单步模式)，这些监视实体被配置为用于通过它们对应的概要分析器将指示所检测到的多个系统调用的信息转发至分析代理，并且等待来自分析代理的用于强制执行的安全决策。该分析代理将指示所检测到的一个或多个系统调用的信息转发至该分析设备，并且基于该分析GUI中的用户输入针对该分析代理生成安全决策。将所生成的安全决策发送至分析代理，然后该分析代理通过其对应的概要分析器将该安全决策转发至监视实体进行强制执行。例如，如何处理系统调用的安全决策由用户来决定，并且所生成的安全决策被转发至分析代理。在一种形式下，在目标设备的分析过程中用户所生成的这个或每个安全决策被存储在一个或多个安全策略文件中，以针对该目标设备生成一个或多个定制安全策略。在某些实施例中，所存储的一个或多个安全策略文件可以由在目标设备或一组类似的目标设备(例如，针对特定用户群组)上运行的安全系统用于将来的强制执行。

在某些实施例中，这些监视实体可以是安全系统的多个组件，在该安全系统内这些监视实体响应于所检测到的多个系统调用基于该安全系统可访问的一个或多个安全策略强制执行多个安全决策。在分析系统的另一种操作模式(例如，登录或策略调试模式)下，这些监视实体被配置为用于基于该安全系统的该一个或多个安全策略来检索并强制执行针对所检测到的系统调用的安全决策，并且然后将指示所检测到的该系统调用的信息以及所强制执行的安全决策通过它们对应的概要分析器转发至该分析代理。然后，由该分析代理将该信息发送至分析设备，以供用户通过该分析GUI来进行分析。

在一个实施例中，目标设备与分析设备之间的数据通信链路可以是有线的，如但不限于USB电缆连接。在另一个实施例中，数据通信链路可以是无线的，如但不限于WiFi或蓝牙。

在某些配置下，该分析代理被配置为用于在将接收自这些概要分析器的信息发送到该分析设备之前将其存储在缓冲器内。

在某些配置下，该分析代理被配置为用于响应于通过该数据通信链路从该分析设备接收到开始指令而开始对指示由在该目标设备上所执行的多个应用进行的多个系统调用的信息进行接收或检索。在一种形式下，该开始指令可以进一步包括该分析代理所应该采用的操作模式。

在一种形式下，该分析代理将所接收到的信息存储在缓冲器内，并且然后在通过该数据通信链路从该分析设备接收到请求指令时使所缓冲的信息流至或者发送至该分析设备。在这种配置下，该分析设备从该分析代理中拉取信息。

在某些配置下，该分析代理被配置为用于响应于通过该数据通信链路从该分析设备接收到停止指令而停止对指示这些系统调用的信息进行接收或检索。

在一个实施例中，该目标设备是智能电话、平板计算机、或具有能够执行应用的操作系统的任何其他可编程设备，并且该分析设备是具有用于该分析GUI以及一个或多个用户输入设备(如触摸屏、鼠标、键盘和/或类似设备)的相关联的显示器的任何可编程设备。

在某些实施例中，该目标设备包括基于Linux的内核以及由与该内核相关联的Linux层以及包括多个应用的更高的应用层所限定的系统架构。在其他实施例中，该目标设备包括包含内核空间和用户空间的架构，其中，该内核空间包括类Unix内核，并且该用户空间包括这些应用。

在某些实施例中，该操作系统是安卓、iOS、Windows或任何其他适合的操作系统。

在第二方面，本发明广泛地包括一种通过显示在通过数据通信链路与目标设备进行数据通信的分析设备上的分析图形用户界面(GUI)来分析在该目标设备上执行的多个应用的方法，该方法包括：

通过该数据通信链路将请求指令发送至该目标设备的分析代理，以请求指示在执行期间由这些应用所发起的多个系统调用的信息；

在该分析设备处通过该数据通信链路从该分析代理接收所请求的该信息；以及

在该分析GUI上向用户显示所请求的该信息。

在一种配置下，该方法进一步包括针对该目标设备上的该分析代理生成开始指令，以发起该分析代理对指示所检测到的在执行期间由多个应用发起的多个系统调用的信息进行接收或检索。在一种形式下，该开始指令可以是通过该数据通信链路生成并且发送至该分析代理的命令。在另一种形式下，该开始指令可以是响应于目标设备与分析设备之间的成功的数据通信链路或连接的建立而生成的。

在实施例中，该方法进一步包括响应于用户输入而针对所检测到的系统调用生成安全决策，并且将所生成的安全决策通过该数据通信链路发送至该目标设备上的该分析代理，以对所检测到的该系统调用进行强制执行。在这种实施例中，该方法可以进一步包括将所生成的每一个安全决策存储在一个或多个安全策略文件中，以针对该目标设备生成一个或多个定制的安全策略。

在另一个实施例中，该方法进一步包括对指示这些安全决策的信息进行请求，这些安全决策由在该目标设备上运行的安全系统响应于所检测到的多个系统调用而强制执行。

在第三方面，本发明广泛地包括一种用于显示在通过数据通信链路与目标设备进行数据通信的分析设备上的分析图形用户界面(GUI)的分析在该目标设备上执行的多个应用的方法，该方法包括：

在该目标设备处直接或间接地从与每一个执行应用相关联的多个监视实体接收或检索指示所检测到的在执行期间由多个应用发起的多个系统调用的信息；

在该目标设备处通过该数据通信链路从该分析设备接收请求指令，该请求指令针对指示在执行期间由这些应用发起的这些系统调用的该信息；以及

将所请求的该信息通过该数据通信链路发送至该分析设备。

在某些实施例中，该方法进一步包括响应于接收到开始指令而对指示在执行期间由多个应用所发起的多个系统调用的信息进行接收或检索。在一种形式下，该开始指令可以是通过该数据通信链路接收自分析设备的命令。在另一种形式下，该开始指令可以是响应于目标设备与分析设备之间的成功的数据通信链路或连接的建立而生成的。

在实施例中，该方法进一步包括在检测到系统调用时暂停应用的操作、并且等待关于如何处理所检测到的该系统调用的执行的安全决策。在一种形式下，该方法包括通过该数据通信链路从该分析设备接收该安全决策。在另一种形式下，该方法包括基于与该应用相关的一个或多个安全策略来生成该安全决策。在此类实施例中，该方法进一步包括将所接收的或所生成的该安全决策发送至与该安全决策所涉及的应用相关联的监视实体进行强制执行。

在某些实施例中，该方法进一步包括通过该数据通信链路将指示针对所检测到的多个系统调用的所生成的这些安全决策的信息与指示所检测到的这些系统调用的信息一起发送至该分析设备。

在第四方面，本发明广泛地包括一种其上存储有计算机可读指令的计算机可读介质，当在处理设备上执行时，这些指令使该处理设备进行前述各方面所限定的这些方法中的任何一种或多种。

在第五方面，本发明广泛地包括一种具有一个或多个处理器的系统或设备，该一个或多个处理器被配置或编程为用于进行或执行前述各方面所限定的这些方法中的任何一种或多种。

其他方面

该安全系统的以下方面和/或特征中的任何一项或多项可以适用于本发明的第一至第三方面。

在一个方面，某些实施例包括一种用于在设备上运行的操作系统的安全系统，该操作系统架构包括：低层，该低层包括在内核模式和用户模式下可操作的内核，在该用户模式下进程对应于高应用层中的应用来执行；以及在与内核相关联的低层与包括多种应用的高应用层之间的中间件层，该系统包括：

在低层的用户模式下运行的主监视进程，该主监视进程被配置为用于通过母进程来检测低层的用户模式下新进程的启动，该新进程对应于由设备的用户所进行的在应用层中新的应用或应用的一部分的启动；

通过主监视器被附加到由母进程所创建的每一个新进程上的进程监视器，并且每一个进程监视器也在低层的用户模式下执行并且被配置为用于监视由其附加进程所进行的对内核的系统调用；以及

在应用层运行的安全系统服务，该安全系统服务可操作用于访问所存储的针对应用层的这些应用的可配置安全策略，并且其与低层中的每一个进程监视器进行通信，这些安全策略对应于其附加进程，并且其中，每一个进程监视器被配置为用于基于所检测到的这些系统调用的那些形参来检索和强制执行针对其附加进程所配置的安全策略。

在另一方面，某些实施例包括一种用于在包括基于Linux的内核的设备上运行(例如，执行)的操作系统的安全系统，以及一种由与内核相关联的Linux层和包括多个应用的高应用层所限定的系统架构，该系统包括：

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

通过主监视进程被附加到由母进程所创建的每一个新进程上的进程监视器，并且每一个进程监视器被配置为用于监视由其附加进程所进行的对内核的系统调用；以及

在应用层运行的安全系统服务，该安全系统服务可操作用于访问所存储的针对应用层的这些应用的可配置安全策略，并且其与Linux层中的每一个进程监视器进行通信，这些安全策略对应于其附加进程，并且其中，每一个进程监视器被配置为用于基于所检测到的这些系统调用的那些形参来检索和强制执行针对其附加进程所配置的安全策略。

在某些实施例中，监视进程被配置为用于通过基于所检索到的安全策略关于所检测到的系统调用在Linux层实现安全动作来针对该监视进程的目标进程强制执行所检索到的安全策略。该安全动作可以包括以下各项中的任何一项或多项：允许进行该系统调用、阻止进行该系统调用、在执行前修改该系统调用的多个形参或在执行后返回由该系统调用所生成的多个值、或提示设备的用户选择安全动作。举例来说，该监视进程可以通过关于内核的由所附加的被监视进程对所请求的系统调用的执行指示并且控制内核来实现安全动作。

每一个进程监视器可以被配置为用于基于从所检测到的这些系统调用中提取的多个形参来强制执行多个安全策略。对于显式系统调用，可以直接基于所提取的多个系统调用形参来对这些安全策略进行评估和强制执行。对于隐式系统调用，这些进程监视器可以被配置为用于在评估和强制执行这些安全策略之前从在应用层中的安全系统服务中检索关于该系统调用的进一步的信息。

在另一方面，某些实施例包括一种用于在包括基于Linux的内核的设备上运行(例如，执行)的操作系统的安全系统，以及一种由与内核相关联的Linux层和包括多个应用的高应用层所限定的系统架构，该系统包括：

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

通过主监视进程被附加到由母进程所创建的每一个新进程上的进程监视器，并且每一个进程监视器被配置为用于监视由其附加进程所进行的对内核的系统调用；以及

在应用层运行的安全系统服务，该安全系统服务可操作用于访问所存储的针对应用层的这些应用的可配置安全策略，并且其与Linux层中的每一个进程监视器进行通信，这些安全策略对应于其附加进程，并且其中，每一个进程监视器被配置为用于基于所检测到的这些系统调用的那些形参来检索和强制执行针对其附加进程所配置的安全策略。

在一个实施例中，该系统架构进一步由在Linux层与高应用层之间的中间件层所限定。

该安全系统可以进一步包括可访问的策略数据库，该策略数据库包括针对应用层中的这些应用的所存储的可配置安全策略。该策略数据库可以被存储在设备上或远程存储，并且可由设备访问。

在某些实施例中，操作系统是安卓。在某些此类实施例中，母进程是Zygote进程。

主监视进程通常被附加到母进程上。可以通过进程跟踪系统调用来创建该附加，其中，主监视器被配置为主进程，并且母进程被配置为目标进程。

每一个进程监视器都可以通过进程跟踪系统调用被附加到其对应的进程上，其中，进程监视器是主进程，并且其对应的附加进程是目标进程。

每一个进程监视器都可以被配置为用于通过从安全系统服务中检索安全策略来针对该进程监视器的附加目标进程加载这些安全策略。每一个进程监视器都可以被配置为用于监视其目标进程的特殊化过程以提取指示该目标进程正在特殊化为的应用的应用标识数据、并且基于所提取的应用标识数据从安全系统服务中检索针对该目标进程的多个相关安全策略。

在某些实施例中，该一个或多个进程监视器通过Linux层与应用层之间的通信链路或机制与安全系统服务进行通信。举例来说，通信机制可以是通过TCP链路或类似链路进行的客户端-服务器事务。

在另一方面，某些实施例包括一种使在设备上运行的操作系统安全的方法，该设备在Linux层内包括基于Linux的内核，包括应用的系统架构在Linux层之上的应用层内包括多个应用，该方法包括：

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

将每一个新启动的进程配置为用于使它的共享或动态库符号调用中的至少某些重定向至该进程内的嵌入式监视实体上；

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

在某些实施例中，这些共享或动态库符号调用对应于或者表示在共享或动态库中的多个函数调用，这些函数调用旨在于内核模式下调用一个或多个系统调用。

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

在某些实施例中，安全动作可以包括以下各项中的任何一项或多项：

●拒绝执行由共享或动态库内的符号所表示的函数调用以阻止该函数调用的执行以及其可能使用的任何一个或多个系统调用的执行，

●通过将函数调用发送至预期的共享或动态库进行执行以允许对该函数调用以及其可能使用的任何一个或多个系统调用进行调用来允许对由符号所表示的函数调用的执行，或者

●通过将修改过的函数调用发送至预期的共享或动态库进行执行以允许对内核内的修改过的系统调用进行调用来修改符号调用。

在每一个新启动的进程中嵌入监视实体可以包括在该进程中嵌入进程监视方法或函数。

将每一个新启动的进程配置为用于使多个共享或动态库符号调用重定向至嵌入式监视实体上可以包括针对每一个新启动的进程来配置函数调用插入(FCI)机制。举例来说，FCI机制被配置为用于拦截多个符号调用并将其重定向至进程内的嵌入的进程监视器。

在一种形式下，FCI机制包括在每一个新进程中配置或提供一组代理函数(代理函数库)，该组代理函数拦截这些符号调用并将它们重定向至每一个进程内的嵌入式监视实体。在某些此类实施例中，该代理函数库被配置为用于拦截旨在用于共享或动态库的多个符号调用。

在第一种形式下，针对每一个进程配置FCI机制包括配置运行时链接器以在任何其他共享或动态库之前将该进程链接至代理函数库。举例来说，该方法可以包括配置LD_PRELOAD环境变量以指示该运行时链接器在启动进程时链接至代理函数库。

在第二种形式下，针对每一个进程配置FCI机制包括修改进程映像以将多个动态链接符号调用重定向至该进程的代理函数库。在某些实施例中，此步骤包括对进程的全局偏移表(GOT)内的那些符号的地址条目进行修改以指向进程的代理函数库内的条目，并且其中，GOT是进程的可执行可链接格式(ELF)的一部分。举例来说，代理函数库形式可以是代理偏移表(POT)，并且POT中的每一个条目可以被配置为指向进程的嵌入式监视实体。

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

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

对由母进程所启动的任何新进程的存储器中的进程映像进行修改，以将多个共享或动态库符号调用重定向至进程的代理函数库上。

举例来说，操作系统可以是安卓，并且母进程可以是Zygote进程。

在另一方面，某些实施例包括一种使在设备上运行的操作系统安全的方法，该设备在Linux层内包括基于Linux的内核，系统架构在Linux层之上的应用层内包括多个应用，该方法包括：

对由多个进程所进行的旨在调用内核中的系统调用的多个共享或动态库符号调用进行拦截；

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

在另一方面，某些实施例包括一种用于在包括基于Linux的内核的设备上运行的操作系统的安全系统，以及一种由与内核相关联的Linux层和包括多个应用的高应用层所限定的系统架构，该系统包括：

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

与每一个进程相关联的拦截器，该拦截器被配置为用于对由其相关联的进程所进行的那些共享或动态库符号调用中的至少某些进行拦截，并且将它们重定向至发起这些符号调用的该进程中的嵌入式监视实体，并且

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

在另一方面，某些实施例包括一种用于使在包括基于Linux的内核的设备上运行的操作系统安全的方法，以及一种由与内核相关联的Linux层和包括多个应用的高应用层所限定的系统架构，该方法包括：

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

创建新的监视实体，以便一旦新启动的进程由母进程所创建即对新启动的进程进行监视，该新的监视实体被配置为用于检测由新进程所进行的多个系统和/或库函数调用、并且基于所检测到的这些系统和/或库函数调用的那些形参对针对该新进程的所配置多个安全策略进行检索和强制执行。

在一个实施例中，该系统架构进一步由在Linux层与高应用层之间的中间件层所限定。

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

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

在另一方面，某些实施例包括一种用于使在包括基于Linux的内核的设备上运行的操作系统安全的方法，以及一种由与内核相关联的Linux层和包括多个应用的高应用层所限定的系统架构，该方法包括：

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

创建新的监视实体，以便一旦新启动的进程由母进程所创建即对新启动的进程进行监视，该新的监视实体被配置为用于直接或间接地检测由新进程所进行的多个系统调用、并且基于所检测到的这些系统调用的那些形参对针对该新进程的所配置多个安全策略进行检索和强制执行。

在一个实施例中，该系统架构进一步由在Linux层与高应用层之间的中间件层所限定。

在一种形式下，这些监视实体通过拦截对内核的系统调用来直接监视或者检测这些系统调用。在另一种形式下，这些监视实体通过拦截多个共享或动态库符号调用来间接监视或检测多个系统调用，这些共享或动态库符号调用旨在调用对内核的一个或多个系统调用。

在某些配置下，监视器可以包括：监视实体，该监视实体对由母进程所调用的多个系统调用进行直接或间接的监视以检测将与应用层中的新应用相对应的新进程的创建，并且其中，该监视器被配置为用于创建新的监视实体，以便一旦新启动的进程由母进程所创建即对新启动的进程进行监视，该新的监视实体被配置为用于直接或间接地检测由新进程所进行的多个系统调用、并且基于所检测到的系统调用的那些形参来对与该新进程相关或相关联的多个安全策略进行强制执行。在一种此类配置下，这些监视实体可以通过拦截对内核的系统调用来直接监视或者检测这些系统调用。在另一种此类配置下，这些监视实体可以通过拦截多个共享或动态库符号调用来间接监视或检测多个系统调用，这些共享或动态库符号调用旨在调用对内核的一个或多个系统调用。

监视器代码可以被配置为用于通过监视多个共享或动态库符号调用和/或系统调用来监视进程与内核的交互，并且该一个或多个策略文件可以定义响应于由与该一个或多个策略文件相关的进程所进行的给定的多个符号调用或系统调用的多个动作。这些动作可以包括以下各项中的一项或多项：阻止符号调用或系统调用、将多个符号调用重定向至替代库地址、登录符号调用或系统调用、取消进程、以及挂起符号调用或系统调用以允许操作员对符号调用或系统调用进行授权。

在某些配置下，监视器可以包括：监视实体，该监视实体对由母进程所调用的多个系统调用进行直接或间接的监视以检测将与应用层中的新应用相对应的新进程的创建，并且其中，该监视器被配置为用于创建新的监视实体，以便一旦新启动的进程由母进程所创建即对新启动的进程进行监视，该新的监视实体被配置为用于直接或间接地检测由新进程所进行的多个系统调用、并且基于所检测到的系统调用的那些形参来对与该新进程相关或相关联的多个安全策略进行强制执行。在一种形式下，这些监视实体可以通过拦截对内核的系统调用来直接监视或者检测这些系统调用。在另一种形式下，这些监视实体可以通过拦截多个共享或动态库符号调用来间接监视或检测多个系统调用，这些共享或动态库符号调用旨在调用对内核的一个或多个系统调用。

在另一方面，某些实施例包括一种设备，该设备包括一个或多个资源，该一个或多个资源包括处理器并且可配置为在由设备所接收的功能代码中限定的多个功能；该设备还包括操作系统，该操作系统包括可操作用于运行进程的用户层以及可操作用于为这些进程提供接口以使用设备的一个或多个资源的内核，其中，该设备存储有启动器代码，该启动器代码可操作用于将所接收到的功能代码作为新进程启动，并且使新进程依赖于功能代码进行特殊化，由此经由内核所提供的接口使用设备的资源通过新进程来执行由功能代码针对设备所定义的功能，其中，该设备还存储有策略代码，该策略代码针对所接收的每一个功能代码或每一种类型的功能代码定义策略，并且其中，该设备包括监视器代码，该监视器代码可操作用于将策略代码的多个实例与多个进程相关联并且依赖于相关联的策略代码来监视进程。

在一种配置下，监视器代码可以被进一步配置为用于对在与进程相关或相关联的该一个或多个策略文件中所定义的该一个或多个策略进行强制执行。

在一种配置下，监视器代码可以被配置为用于通过监视多个共享或动态库符号调用和/或系统调用来监视进程与内核的交互，并且该一个或多个策略文件定义响应于由与该一个或多个策略文件相关的进程所进行的给定的多个符号调用或系统调用的多个动作。在一种形式下，这些动作可以包括以下各项中的任何一项或多项：阻止符号调用或系统调用、将多个符号调用重定向至替代库地址、登录符号调用或系统调用、取消进程、以及挂起符号调用或系统调用以允许操作员对符号调用或系统调用进行授权。

在一种配置下，监视器代码可以包括：监视实体，该监视实体对由母进程所调用的多个系统调用进行直接或间接的监视以检测将与应用层中的新应用相对应的新进程的创建，并且其中，该监视器代码被配置为用于创建新的监视实体，以便一旦新启动的进程由母进程所创建即对新启动的进程进行监视，该新的监视实体被配置为用于直接或间接地检测由新进程所进行的多个系统调用、并且基于所检测到的系统调用的那些形参来对与该新进程相关或相关联的多个安全策略进行强制执行。在一种形式下，这些监视实体通过拦截对内核的系统调用来直接监视或者检测这些系统调用。在另一种形式下，这些监视实体通过拦截共享或动态库符号调用来间接监视或检测多个系统调用，这些共享或动态库符号调用旨在调用对内核的一个或多个系统调用。

在另一方面，某些实施例包括一种方法，该方法使在包括Linux层和中间件层的系统内执行的多个应用的操作安全，该中间件层可操作用于通过使Linux层内的这些进程产生自其他进程或产生自母进程来启动多个应用、并且通过特定于该应用的代码进行特殊化，该方法包括：

监视母进程或现有进程以检测所产生的进程；

监视所产生的进程执行以便标识已经特殊化为哪个进程；并且

监视由特殊化的进程所进行的多个函数调用以确定关于函数调用所强制执行的安全动作。

在另一方面，某些实施例包括一种其上存储有计算机可读指令的计算机可读介质，当在处理设备上执行时，这些指令使该处理设备进行前述各方面的实施例中所限定的这些方法中的任何一种或多种。

在另一方面，某些实施例包括一种具有处理器的系统或设备，该处理器被配置或编程为用于进行或执行前述各方面的实施例中所限定的这些方法中的任何一种或多种。

定义

如在本说明书和权利要求书中所使用的，短语“特殊化过程”或术语“特殊化”意在指(除非上下文另有提示)这样的进程，通过该进程，新创建的进程例如在基于Linux的操作系统的Linux层中标识与其相关的在应用层中的相应应用、并且然后针对该应用检索并加载应用特定代码进行执行，或类似地，在其他基于Unix或Linux的操作系统(包括安卓、iOS、Chromium、以及ChromiumOS)中的此类进程。

如在本说明书和权利要求书中所使用的，术语“附加(attached)”或“附加(attaching)”意在指(除非上下文另有提示)创建Linux层中的两个进程之间的关系，其中一个进程被配置为用于以父-子关系或主-目标关系来监视并控制另一个进程，并且作为示例包括借助于进程跟踪系统调用(例如，ptrace)的附加，或任何其他创建进程间的联系或附加的机制，该联系或附加使得一个进程能够控制另一个进程的一个或多个方面或功能。

如在本说明书和权利要求书中所使用的，术语“Linux”意在指(除非上下文另有提示)采用Linux或Unix或类Unix内核的任何基于Linux的操作系统。

如在本说明书和权利要求书中所使用的，短语“Linux层”意在指(除非上下文另有提示)操作系统架构中用于描述用户模式(用户层)下多个进程的操作以及内核模式(内核层)下它们与内核的交互的层。

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

如在本说明书和权利要求书中所使用的，短语“应用层”意在指(除非上下文另有提示)操作系统架构中用于描述用户应用软件和服务的运行的层。

如在本说明书和权利要求书中所使用的，短语“母进程”通常意在指(除非上下文另有提示)在操作系统引导之后运行的通过与内核的交互来控制Linux层的所有新的子进程的启动或发起的进程，并且例如在安卓的上下文下相当于通过分支出(fork)其自身的新复本或映像来发起新进程的Zygote进程，并且例如在Chromium或ChromiumOS的上下文下相当于通过分支出或产生其自身的复本或映像来初始化新进程的运行浏览器的主进程，并且还可以被称为“父进程”。

如在本说明书和权利要求书中所使用的，术语“分支(fork)”、“分支(forking)”、“分支(forked)”意在指(除非上下文另有提示)新进程的创建或产生，并且其中通常在基于Linux的OS中新进程由母进程创建或产生并且作为母进程的复本或映像启动，但是这些术语意在指通过其来发起或创建新进程的任何其他机制。

如在本说明书和权利要求书中所使用的，术语“监视”意在指在主-目标进程关系的上下文下，其中主进程对由目标进程所进行的对内核的系统调用进行拦截、控制、修改和/或跟踪，并且还可以包括或者在技术上被称为“插入(interposing)”和/或“交叉(interleaving)”。

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

如在本说明书和权利要求书中所使用的，短语“系统调用网关”意在指(除非上下文另有提示)系统调用将要或正在被执行的内核中的入口点。

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

如在本说明书和权利要求书中所使用的，短语“函数调用”、“符号调用”、“共享或动态库符号调用”或“共享对象库函数调用”意在指(除非上下文另有提示)由进程所进行的可以旨在调用内核模式下的一个或多个系统调用的对共享或动态库的函数调用。

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

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

如在本说明书和权利要求书中所使用的，术语“包括(comprising)”是指“至少部分地由...组成”。在解释本说明书和权利要求书中的包括术语“包括(comprising)”的每一个表述时，还可以存在除了该术语前述的那个或那些之外的特征。以相同的方式来解释相关的术语，如“包括(comprise)”和“(comprises)”。

如在此所使用的，术语“和/或”是指“和”或“或”或两者。

如在此所使用的，名词之后的“(s)”是指名词的复数和/或单数形式。

各实施例在上文包括并且还设想了多种构造，以下仅给出这些构造的示例。

在以下描述中，给出了特定细节来提供对实施例的透彻理解。但是，本领域技术人员将理解，可以在没有这些特定细节的情况下实践实施例。例如，可以在框图中示出软件模块、函数、电路等，以免用不必要的详情而模糊实施例。在其他例子中，为了不模糊实施例，可以不详细示出公知的模块、结构与技术。

同样，要注意的是，实施例可以被描述为过程，该过程被描绘为流程图、结构图或框图。虽然流程图将这些操作描述成顺序过程，但这些操作中的许多操作可以并行地或同时地执行。另外，可以重新布置操作的顺序。当操作完成时过程结束。过程可以对应于计算机程序中的方法、函数、流程、子例程、子程序等。当过程对应于函数时，其终止对应于函数返回至调用函数或主函数。

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

附图说明

在此将仅通过举例的方式并且参照附图来描述各实施例，在附图中：

图1是安卓操作系统的示意图，并且示出了IPC机制的示例；

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

图3是根据第一实施例的用于安全系统的基于系统调用插入(SCI)的框架基本架构的示意图；

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

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

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

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

图8是根据第二实施例的用于安全系统的基于函数调用插入(FCI)的框架基本架构的示意图；

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

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

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

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

图12是与新应用相对应的新进程的启动的时间线以及根据实施例的后期安全策略绑定机制；

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

图14是运行操作系统(如安卓)的设备内的典型存储设备分区的示意图；

图15是Chromium的示意图；

图16是在第三实施例中应用于Chromium的安全系统的示意图；

图17是根据实施例的用于分析和/或概要分析在目标设备上执行的应用的分析系统的示意图；

图18是根据实施例的用于系统的概要分析器之间的数据通信中的对图17的分析系统中的目标设备搭载的分析代理的IPC调用的数据结构(并且具体地是进程数据(ProcessData)数据结构以及进程数据(ProcessData)数据结构的系统调用Info(SystemCallInfo)数据结构)的示意图；

图19是根据实施例的图18的系统调用Info数据结构的形参数据结构的示意图；

图20是根据实施例的由图19的形参数据结构所使能的多级数据结构的树形表示的示意图；以及

图21是根据实施例的图17的分析系统所利用的决策数据结构的示意图；

具体实施方式

1.分析系统的概述

分析系统可以用作概要分析器工具以供安全专家或管理员来分析运行时多种应用的执行，以标识恶意/可疑行为、配置合适的安全策略以供安全系统应用到多种应用中、和/或分析并改进现有的安全策略的性能，例如，用于策略调试。

在实施例中，分析系统是在设备上运行的基于策略的安全系统的扩展。将首先参照图2至图16通过举例来描述安全系统的多个实施例，接着是参照图17至图21描述分析系统的实施例。

2.安全系统的概述

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

安全系统适用于安卓操作系统或具有类似结构或配置的其他计算机体系结构。安全系统利用一种允许监视用户空间代码而不需要修改安卓框架或底层Linux内核的方式。具体地，安全系统提供一种被配置为用于控制应用之间的进程间通信(IPC)或组件间通信(ICC)以减轻恶意软件可能在敏感应用及其数据上进行的攻击的方式。原则上，在此某些实施例能够对在安卓OS上运行的任何进程控制并且强制执行安全策略。这包括在安卓商店(如SMS服务、活动管理器(ActivityManager)、服务管理器(ServiceManager)等)中所提供的多种系统服务。以此方式，各种实施例减轻了这些安卓服务中存在的可能被恶意代码利用的漏洞。

安全系统基于安卓特有的特点来实现，即，被称为Zygote的母进程。每一个安卓应用作为从Zygote母进程中分支出来的子进程运行，并且然后它通过加载特定应用包以及其内的所有类来将其自身特殊化为特定应用，并且利用Java反射，它将最终通过调用静态主方法来启动应用。通常，每一次启动新的应用，安全系统利用Zygote进程来配置与Linux层上新启动的进程相关联的监视实体。此监视实体可以在一种形式下是一种嵌入式进程监视方法或函数(如添加到存储器中新进程的映像上的附加码)，或可替代地，在另一种形式下是一种附加到新启动的进程上并且对其进行监视的单独进程。安全系统能够强制执行一组安全策略，该组安全策略可以由安全系统自身内部或外部的多个源提供，如系统管理员、设备用户、第三方服务或系统、安卓应用或这些的组合。

安全系统使得能够对应用层的应用特定的安全策略进行规范或配置，这些安全策略可以在Linux层中进行强制执行。将具体参照安卓设备上的安卓操作系统通过举例来描述安全系统。然而，将认识到，安全系统可以被配置为用于在具有类似于安卓的架构的任何其他合适的操作系统、或使用母进程来发起Linux层中的新进程的任何其他操作系统或平台(不管是移动的或以其他方式)上操作，如但不限于Linux操作系统、Unix操作系统、或例如像iOS这样的移动操作系统。

安全系统可以被配置为用于监视由内核代表进程所执行的系统调用。具体地，安全系统被配置为用于基于针对与进程相对应的应用的安全策略设置来针对由进程所进行的系统调用监视并且实现安全动作。安全动作可以包括防止执行系统调用、修改系统调用形参、修改系统调用的返回值、允许取决于针对发起系统调用的进程所规定的安全策略执行系统调用、或强制结束进程。

系统调用是由内核代表进程所执行的特殊函数。它们被看作低级操作，内核将这些低级操作作为进程提供对内核所管理的多个服务的访问的服务而执行。通常，通过系统调用号和硬件中断来使系统调用对用户模式代码可用，并且通过链接到进程代码的库函数来频繁地调用系统调用。在可执行可链接格式(ELF)中，库是一种特殊类型的目标代码，其提供了可以从其他目标代码中导入的可再用符号。库的特殊情况是旨在由可执行文件和其他共享对象所共享的共享对象(或共享库)。

共享对象可以或者是静态链接或者是动态链接的。在前一情况下，这些符号在链接时间期间被复制到目标文件中，而在后一情况下，这些符号在执行期间被解析。动态链接符号可以在或者将进程映像加载到存储器的过程中或者在它们第一次被使用时(其被称为延迟绑定)被解析。

libc库是所有的基于Linux的系统上的公共组件，并且除了其他事情以外，它提供了可以被用来从用户模式代码中调用系统调用的一组函数。安卓提供了其自身的libc实现，即，Bioniclibc。与正常的Linux配置相比，安卓的特殊特征是libc被动态链接以减少进程存储器占用。这意味着通常被可执行文件用于调用系统调用的那些符号是动态链接的。

图2提供了这种系统调用机制的概图。举例来说，当进程1进行对Binder4的ioctl系统调用3时，它实际上调用了由libc.so5所提供的ioctl函数(2)。这个函数将调用内核中的ioctl系统调用3，并且操作将在管理模式下执行6。

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

参照图3至图7，将描述利用SCI机制或配置的安全系统的第一实施例。参照图8至图11，将描述利用FCI机制或配置的安全系统的第二实施例。

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

概述

在此第一实施例中，安全系统运行附加到Zygote进程上的系统进程并且拦截所有其fork系统调用，从而使得无论何时fork系统调用被拦截，安全系统都开始监视新进程并且强制执行针对那个特定安卓应用的特定安全策略。

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

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

现将参照图3至图7对第一实施例安全系统进行更加详细的描述。

安全系统的主要组件

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

监视器202、204(监视实体)负责针对一个或多个进程强制执行一组安全策略并且被实现为Linux进程。这些监视器包含策略强制执行点以及策略决策点，稍后将对其进行描述。在本实施例中，存在被配置为用于监视Zygote系统进程208的单一主监视器202。这些进程监视器204中的其余的监视器从此主监视进程中分支出来。可以有零个或更多个应用监视器204，每一个从Zygote进程中分支出来的安卓应用210一个应用监视器。在拦截到来自Zygote进程的fork系统调用时，进程监视器204被创建为主监视器202的子监视器。与被配置为用于监视主Zygote线程的主监视器202相反，这些单独的进程监视器204被配置为用于监视属于它们所附加的应用的所有的线程和子进程。

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

示例配置和操作

现将参照图4至图6中的示例对安全系统配置和这些主模块的功能的进一步解释进行描述。图4对应于图1中所描述的架构，并且同样的标号表示同样的部分。简言之，Linux层中属于安卓应用10、12的每一个Linux进程18、20具有其自身的分别在52、54处示出的附加进程监视器。每一个进程监视器52、54被配置为用于拦截附加Linux进程18、20代表其相关联的应用10、12所执行的那些系统调用的全部或子集。当每一个Linux进程执行系统调用时，附加进程监视器拦截该系统调用并且基于与应用相关联的安全策略来采取安全动作，这表明该Linux进程是否具有执行那个系统调用的授权。举例来说，进程监视器可以被配置为用于允许系统调用、阻止系统调用、修改系统调用的那些形参、修改系统调用返回的那些值或其他合适的安全动作、或这些的组合。如果Linux进程被授权执行系统调用，进程监视器允许系统调用的执行。可替代地，进程监视器可以阻止系统调用执行或以其他方式修改那些系统调用形参或返回值。例如，进程监视器能够检索系统调用的那些形参以及另外系统调用所返回的那些值。这使得进程监视器能够例如通过在执行之前取决于用于应用的所配置的安全策略过滤掉一个或多个返回值或改变或修改系统调用的一个或多个形参来修改系统调用。另外，可以取决于系统调用的多个形参的值来采取多个安全动作。举例来说，针对可能由于被阻止的系统调用而崩溃的应用，进程监视器可以被配置为用于修改系统调用而不是阻止系统调用。

举例来说，进程监视器52可以被配置为用于拦截IPC，其使用多个系统调用34来与Binder子系统30接口连接。这可以通过拦截目的地是Binder内核驱动32的open和ioctl系统调用38来完成。然后，进程监视器52基于针对应用层中的相关联的应用10所配置的安全策略以及从进程执行状态中所提取出来的其他形参来决定是否阻止系统调用或者允许系统调用在其原始状态或经修改的状态下进行，如在56处所示。

由主监视器来创建每一个进程监视器，该主监视器是对任何应用进行发起之前设备引导时所创建的Linux进程并且稍后将对其进行更加详细的解释。规定对安装在应用层中的设备上的那些应用的授权、并且具体地是哪个应用可以彼此进行通信或采用彼此的服务或许可或其他敏感的存储数据的安全策略是可配置的，并且由应用层中的安全系统服务器进行存储和/或检索，稍后将对安全系统服务器进行更加详细的解释。这些安全策略可以存储在本地设备上或远程地在设备可访问的外部存储容量、服务器或网络上的存储器中。

通过将每一个进程监视器作为主进程进行建立以及将相关联的Linux进程作为其目标进程进行建立并且使用跟踪系统调用来将该进程监视器附加到其相应的Linux进程上，该跟踪系统调用被配置为用于通过检查其存储器和多个寄存器并且拦截其多个系统调用来使主进程控制目标进程。在本实施例中，跟踪系统调用是进程跟踪系统调用(ptrace)。要使用ptrace，主进程必须或者作为根用户来运行或者相同的用户作为目标进程来运行。主进程将变为目标进程的父进程，并且将能够对由目标进程所创建的所有子进程和线程进行监视和控制。

如所提及的，安全系统被配置为用于通过利用安卓OS的配置特征来对在安卓设备上执行的所有应用和相应的进程进行监视，该安卓OS控制多个应用的管理和启动。在安卓中，应用层中的所有应用都是通过特殊的母进程(被称为Zygote进程)来启动的。该Zygote进程是唯一有权限创建新安卓应用及其相应的Linux进程的进程。因此，在安卓上执行的所有的安卓应用及其相应的Linux进程实际上都是这个Zygote进程的子进程。现将对安全系统的配置和这些主模块的操作进行更加详细的描述。

安全系统启动

安全系统作为安卓操作系统的一部分启动。如所提及的，安全系统控制母进程或Zygote进程，从而使得每一次启动新的Linux进程(对应于安卓应用)，可以将新的监视器附加到进程上。通过修改安卓操作系统的启动顺序来实现对这些Zygote进程的控制。

举例来说，修改引导顺序，从而使得安全系统的主监视器代替初始的Zygote进程。在引导过程期间，运行初始化脚本，并且启动主监视器。然后，将Zygote进程作为主监视器的子进程启动。然后，主监视器执行跟踪系统调用(如ptrace(请求＝PTRACE_ATTACH))来附加到子Zygote进程上，以通过拦截Zygote进程所进行的对内核的系统调用来从子Zygote进程开始的第一时刻开始控制它的执行。具体地，每一次目标Zygote进程进入或退出系统调用时，ptrace(请求＝PTRACE_SYSCALL)系统调用被用于通知内核主监视器应该接收到通知。此时，在引导中，主监视器现被附加到Zygote进程上并且对其进行监视。

在本实施例中，在引导过程期间，安全系统服务还由安卓操作系统启动。举例来说，安全系统服务位于用于多个系统应用的目录内，从而使得其在用户可以登录到安卓设备上或任何用户应用可以在安卓设备上运行之前启动。一旦安全系统服务运行，每一次从Zygote中分支出来新的安卓应用，新的进程监视器从主监视器中分支出来并且附加到该新的应用进程上，如以下更详细解释的。

针对新启动的安卓应用生成进程监视器

概述

将描述针对新启动的安卓应用生成和配置进程监视器安全系统所执行的主操作的顺序。当安全系统启动时，只有主监视进程连同安全系统服务在运行。主监视器被附加到Zygote进程上并且对其进行监视。由于在安卓中每一次启动新的应用时都会调用的Zygote进程所进行的fork系统调用，新的进程监视器作为主监视器的子监视器被创建。具体地，主监视器被配置为用于检测由Zygote进程所进行的fork系统调用，并且针对启动的每一个新的应用创建新的进程监视器。

参照图5，将使用用户在其安卓智能电话上启动Skype应用的场景来进行举例。当用户点击其智能电话上的Skype图标时，消息或信号60被发送至Zygote进程62以分支出新的进程74，该新的进程在用于Skype应用的DVM的复本中执行。

每一次Zygote62调用fork系统调用64，它将被内核66挂起65，并且主监视器70将由内核通过信号68(例如SIGCHILD)通知并唤醒。因为主监视器70正在通过ptrace系统调用监视Zygote62，内核对这些信号进行分派。现在，通过从主监视器70中调用fork系统调用来创建新的进程监视器72，并且一旦被分支出来，它将附加到新创建的进程74上。

由于Linux调度器所进行的调度，无法保证进程执行顺序在它执行任何系统调用前将允许新的进程监视器72附加到对应于Skype应用的新Linux进程74上。在某些情况下，新进程74可以开始执行其代码，而进程监视器72不能够控制新进程，这可能导致安全问题。

为了避免这种情况，主监视器被配置为用于将断点76(例如，无限循环77)注入到Zygote进程代码中，从而使得当复制其映像以创建新进程74时，新的复本将同样包含那个断点。现在包含断点77的新进程74初始被卡在进程中，因此直到断点被进程监视器移除其才将能够执行任何其他代码。这恰好在进程监视器72已经通过ptrace有效地附加到新进程74上之后进行。举例来说，断点可以是断点机器指令、ARM汇编码中的无限循环或任何其他的停止在使用其他指令集的多个处理器上的程序执行的等效方法。以下将进一步描述用于本实施例的断点注入的示例以及剩余的进程监视器72生成。

断点注入

如上所述，每一次新的安卓应用74从Zygote62中分支出来时，安全系统向Zygote62内注入断点76，从而使得在复制其映像时，新进程74将同样包含该断点，并且新进程监视器72可以在新进程继续其执行之前附加到新进程上，而不错过任何系统调用。

如所提及的，“断点”76可以是例如ARM汇编码中的无限循环。使用以下流程在Zygote进程存储器内的当前程序计数器地址(PC)处注入断点76如下。首先，为了恢复Zygote程序执行，应该将Zygote寄存器的状态以及将由断点本身所代替的Zygote程序代码备份在主监视器70的存储器内。举例来说，主监视器70可以使用允许从被监视进程存储器(在这种情况下是Zygote)中读取数据的ptrace(PTRACE_PEEKDATA)将Zygote进程映像的部分复制到其自身的存储器中。主监视器可以使用ptrace(PTRACE_GETREGS)读取并且存储其自身存储器中的这些Zygote进程寄存器的状态。此后，主监视器70被配置为用于将PC复位至其前一个地址(将在稍后包含断点)，从而使得其在注入的断点代码处继续其执行。使用使能断点的ptrace(PTRACE_SETREGS)来将Zygote62的寄存器R1设置为零。接下来，主监视器被配置为用于向Zygote注入断点代码。主监视器70包含函数，该函数包含执行无限循环(基于R1的值)的内联ARM汇编码，并且这是被注入到Zygote进程存储器中的代码。断点函数机器代码作为字节数组从主监视器存储器中的函数地址处获得。然后，使用允许跟踪器将数据插入到被监视进程存储器空间的ptrace(PTRACE_POKEDATA)将断点代码从主监视器存储器中复制到在程序计数器地址处的Zygote存储器中。

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

一旦已经如上将断点代码注入到Zygote中，主监视器70调用ptrace(PTRACE_SYSCALL)78来通知内核以允许执行Zygotefork系统调用的内核空间代码。在fork系统调用执行80时，创建新进程74(在本示例中最终指的是Skype)。新进程74是Zygote62的克隆，这意味着它是存储器中的Zygote进程映像的副本，包括注入的断点。然后，新创建的进程74可以运行，并且在断点循环77处停止。然后，主监视器70被配置为等待，直至其接收到fork系统调用退出通知。具体地，主监视器70被配置为用于针对退出通知进行监视并且拦截退出通知。

创建新进程监视器

当fork系统调用返回到Zygote中时(系统调用退出)，进程仍将被停止66，并且内核将通过信号82(例如，SIGCHILD)来通知主监视器70。此时，新进程74的进程标识(PID)已经可用，因为它作为fork系统调用的返回值被提供。每一个进程具有允许内核标识不同进程运行的唯一PID。主监视器70被配置为用于从Zygote中检索新进程74的PID，如在84处所示。例如，主监视器70可以使用ptrace(PTRACE_GETREGS)从Zygote进程寄存器R0中检索PID。然后，主监视器70被配置为用于生成将要附加到所检索出的那个PID上的新进程监视器72。

主监视器70通过执行对内核66的fork系统调用88来分支出新的进程监视器72。当主监视进程分支出90新进程时，新创建的进程监视器72在其执行父主监视进程的精确复本的开始。这意味着当主监视器70分支出新的进程监视器72时，进程监视器在其存储器中具有新进程74(最终指的是Skype)的PID，该新进程由Zygote62所创建并且从Zygote寄存器中检索。

然后，主监视器70被配置为用于使用ptrace(PTRACE_POKEDATA)来以备份在原始位置的原始代码代替Zygote62中的断点代码，并且使用ptrace(PTRACE_SETREGS)将这些寄存器复位至它们原始的存储值，如在91处所示。然后，主监视器将Zygote的PC复位至其备份的值并且通过ptrace(PTRACE_SYSCALL)93请求内核继续Zygote进程，通过SIGCONT信号95恢复Zygote进程，并且等待进一步的fork调用。

新创建的子进程监视器72使用其存储器中的PID来附加其自身以使用ptrace(PTRACE_ATTACH)跟踪新的Skype进程，如在92处所示。进程监视器72还被配置为用于以一个特定于其所监视的应用的主虚拟策略决策点来替代来自主监视器的主虚拟策略决策点(如在94处所示)，直至知道与被监视的新进程74相关联的应用包名称(在这种情况下是Skype)，该进程监视器才将会包含任何安全策略。一旦被附加，进程监视器72能够跟踪新进程74，因此它可以被配置为用于以原始代码替代新进程74中的断点代码(如在96处所示)，并且通过将SIGCONT98递送至新进程74的ptrace(PTRACE_SYSCALL)97发起新进程的执行。这通过一种类似于如以上所讨论的主监视器70替代Zygote进程62中的断点代码的方式来完成。被监视的新进程74现在可以开始执行。因为进程监视器72被附加到新进程74上，它可以拦截并且控制这个进程所执行的所有系统调用。

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

此时，将有主监视器70跟踪/监视Zygote62以及新的进程监视器72跟踪/监视还没有被特殊化为Skype安卓应用的新创建的Linux进程74。新的Linux进程74没有执行Skype应用的代码，并且在这个较早的阶段，无法知道该进程将属于哪个应用。这意味着，直至新进程74特殊化，新的进程监视器72的特定安全策略才能被加载。安全系统被配置为用于基于应用标识数据来向新的进程监视器72检索并且加载特定的安全策略或一组策略，该应用标识数据指示新的Linux进程74特殊化为的安卓应用。在本实施例中，应用标识数据是该应用的包名称，并且进程监视器72被配置为用于在它所监视的新进程74进行特殊化的期间对应用标识数据进行检索。

为进行特殊化，新进程74需要进行检索或访问Skype应用包名称，从而使得它可以然后从设备上的应用数据库中加载Skype应用特定字节代码进行执行。在特殊化过程或阶段期间，安卓框架将该应用的包名称写入特殊化文件内(例如，/proc伪文件系统内的/proc/self/cmdline)。这恰好在分支出新进程74之后以及使用反射来调用静态主方法之前发生，这意味着还没有执行开发者代码。

安卓进程Jave类(android.os.Process)通过Java本地接口(JNI)调用设置包名称为形参的函数android_os_Process_setArgV0。这将内在地调用对进程argv[0]进行复位的ProcessState::setArgV0()方法，该方法有效地改变了特殊化数据文件(即，使用该应用的包名称来升级该文件)，并且然后在这之后使用prctl(PR_SET_NAME)系统调用来设置进程名称。可以通过prctl()系统调用设置的进程名称被限于16字节，这意味着，在某些情况下，此系统调用中的包名称可能不是完整的。当将argv[0]形参设置在实际上包含整个包名称的特殊化数据文件中时，被监视进程74没有产生系统调用。

在本实施例中，进程监视器72被配置为用于读取包含在argv[0]被盖写时所设置的完整应用包名称的特殊化数据文件，而不是检查由prctl()函数形参所指定的应用名称。具体地，进程监视器72被配置为用于使用PR_SET_NAME值集来检测prctl()系统调用何时退出。一旦这个被检测到，进程监视器72就知道完整的应用包名称已经被写入特殊化数据文件。然后，进程监视器72被配置为用于在检测到prctl()系统调用退出时从特殊化数据文件中读取并且检索完整的应用包名称。

一旦进程监视器72已经获得了包名称(例如，com.skype.apk)，然后它可以对特定于那个应用的一个或多个安全策略进行检索和加载。具体地，可以对这些进程监视器策略进行初始化，并且可以将这些策略特定于那个进程进行强制执行。包名称被转发至进程监视器的策略决策点，该策略决策点将针对被监视进程加载这些特定的策略。为此，进程监视器74可以利用应用层框架中被称为安全系统服务的特殊服务，稍后将对安全系统服务进行更详细的描述。

监视器操作

概述

每一个进程监视器被配置为用于通过基于所检索到的安全策略关于所检测到的系统调用在Linux层实现安全动作来针对该进程监视器的附加新进程强制执行所检索到的安全策略。该安全动作可以包括以下各项中的任何一项或多项：允许进行该系统调用、阻止进行该系统调用、或在执行前修改该系统调用的多个形参或在执行后返回由该系统调用所生成的多个值。举例来说，该监视进程可以通过关于内核的由所附加的被监视进程对所请求的系统调用的执行指示并且控制内核来实现安全动作。以下解释对策略进行强制执行的示例性实现方式，尽管将认识到，可以使用替代性强制执行机制。

在本实施例中，该主监视进程和这些进程监视器各自包含两个组件，即策略强制执行点和策略决策点。策略强制执行点负责通过其多个系统调用来跟踪被监视进程并且强制执行这些策略，并且向策略决策点提供来自进程状态的信息。策略决策点基于进程状态以及分配给它的这些策略生成多个决策。这些决策被发送给强制执行点，该强制执行点确保它们被强制执行。

策略决策点使用策略储存库，该策略储存库取决于用于每一个决策点的安全系统配置，并且如果配置最终被修改，策略储存库可能在运行时改变。取决于监视器属于哪个类型(例如，主监视器或单独的进程监视器)，监视器将包含不同类型的策略决策点。

主监视器包含虚拟决策点，该虚拟决策点被用于拦截fork()系统调用并且检索新进程的PID以便生成新的应用进程监视器，如先前所解释的。

相反，这些进程监视器能够检索与它们对应的目标进程相关联的应用包名称并且进行策略初始化。举例来说，可能有各种类型的由进程监视器支持的策略，例如：

●IPC拦截：拦截产生自被监视进程的进程间调用。为了做到这一点，它拦截目的地是Binder伪设备(/dev/binder)的那些ioctl()系统调用。

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

●共享存储器：通过共享存储器来阻止进程间通信。确切地，阻止对各种安卓共享存储器服务安卓共享存储器(ashmem)、进程内存分配器(PMEM)以及处理器特定变体(CMEM、NVMAP等)以及安卓ION内存分配器的访问。此外，可以防止子进程与其父进程使用共享存储器机制。

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

●电话、短信服务(SMS)以及多媒体消息服务(MMS)：阻止进程访问安卓上的电话、SMS和/或MMS服务。如果需要，可以设置策略以防止进程发起电话呼叫或向特定号码或联系人发送SMS或MMS消息。

●用户身份模块(SIM)访问：阻止进程访问来自安装在设备内的SIM卡的敏感信息；如集成电路卡识别码(ICCID)、国际移动用户识别码(IMSI)、认证密钥(Ki)、定位区域标识(LAI)、所存储的SMS消息、非结构化补充业务数据(USSD)代码以及联系人列表。

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

●近场通信：阻止进程使用近场通信(NFC)或其他类型的无线通信以建立新的连接或监视已经在进行中的通信会话。

●企业权限管理(ERM)策略：用于管理企业或数字资产的策略。数字资产意在指存储在设备上的文件，或者在存储内存中或者在运行时内存中。这些文件可以例如定义应用或其他数据，如但不限于SMS、电子邮件、图片或承载或定义信息的任何其他数据项。通过ERM策略，当设备上的应用试图访问数字资产时，拥有数字资产的实体(例如，企业或组织)保持数字资产生命周期管理的控制。ERM策略可以被配置并强制执行以控制使用数字资产的方式，或者触发对数字资产的修改或将其从设备上完全删除。ERM策略可以被配置为使得在应用进行对数字资产的访问之前、已经结束对数字资产的访问之后或两者进行安全动作。ERM策略可以被配置为使得在正被访问的文件上进行安全动作，不管这些这些文件是在存储内存还是运行时内存(例如，RAM)中。举例来说，ERM策略可以定义以下各项安全动作中的任何一项或多项在应用访问数字资产之前进行：

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

■消密——移除或过滤掉不应被披露给正在访问数字资产的应用的任何信息

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

■水印/指纹识别——向数字资产中添加防篡改信息

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

○如果数字资产是加密的，对其进行解密

○删除数字资产

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

■计数读/写访问

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

○登录访问信息(如，上下文)

举例来说，ERM策略可以定义以下各项安全动作中的任何一项或多项在应用已经完成对数字资产的访问之后进行：

○修改数字资产以移除或添加信息，例如：如上的消密、版本控制、水印/指纹识别和/或时间戳

○加密数字资产

○删除数字资产

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

策略强制执行机制

如所讨论的，主监视器70和这些进程监视器是Linux层中的分别被附加到Zygote和任何应用进程上的进程。跟踪系统调用被用来将主监视器70和这些进程监视器附加到它们对应的目标进程上。在本实施例中，进程跟踪(ptrace)系统调用被用来将主监视器70附加到其目标进程上，即Zygote进程62，并且将每一个进程监视器附加到其对应的目标进程上。一旦执行ptrace系统调用来将监视器附加到目标上，这些目标进程变成它们对应的监视器或父进程的子进程。

关于这些进程监视器，在本实施例中，ptrace被配置为用于跟踪目标进程主线程(默认)并且还有其余的进程线程和子进程。这种跟踪在某些实施例中是有用的，如关于通常是多线程应用的安卓应用。通过以这种方式配置ptrace，这保证了这些进程监视器将接收到由每一个单线程所执行的任何系统调用以及起源于根应用进程的进程的通知。

策略强制执行机制发生在每一个监视器内的策略强制执行点中。策略强制执行点通过跟踪这些被监视进程系统调用并且基于可以从这些被监视进程系统调用中提取出来的信息做出决策来对策略进行强制执行。

这些进程监视器附加到它们对应的目标进程上(使用例如ptrace(PTRACE_ATTACH))，并且然后，它们通知内核每一次它们的目标进程执行系统调用(使用例如ptrace(PTRACE_SYSCALL))它们都应该被通知。

一旦已经进行此设置，这些进程监视器在附加到被监视的目标进程上之后进入睡眠(例如调用waitpid())。这阻止了进程监视器，直至系统调用由被监视的目标进程调用。当系统调用由目标进程进行时，内核将挂起该目标进程执行并且将解除阻止进程监视器(例如使用SIGCHILD信号)。waitpid()函数将返回生成该系统调用的线程的ID(TID)以及用于其他目的的某些附加进程状态信息。此时，进程监视器被配置为用于从可以获得系统调用号的地方检索那些被监视进程寄存器的状态。线程ID、系统调用号以及这些进程寄存器的状态被转发至策略决策点，该策略决策点取决于其策略将考虑系统调用是否相关。如果不相关，它将立即返回零决策至强制执行点。如果相关，策略决策点将分析进程状态，并且取决于该进程状态，它可以或可以不返回决策至强制执行点，例如，要执行的安全动作。稍后将更加详细地解释决策产生机制。在决策点返回之后，强制执行将继续被监视进程(如果决策指示这样做的话)或实现决策所指示的任何其他安全动作，包括阻止系统调用、修改系统调用的多个形参或修改多个返回值、请求用户输入以供实现用户选定的安全动作、或甚至完全取消应用进程。在该进程被允许继续的情况下，并且在决策被强制执行之后，进程监视器将通知内核继续进程执行(例如，ptrace(PTRACE_SYSCALL))并且返回睡眠(例如，调用waitpid())，等待由目标被监视进程进行的下一个系统调用的通知。

策略生成机制

决策是必须被执行以便强制执行一组策略的安全动作。每一个进程监视器内的策略决策点是负责决策生成的组件，决策生成在每次策略强制执行点拦截到系统调用时发生。在本实施例中，取决于监视器类型以及用于被监视应用的安全系统配置，每一个策略决策点包含一组策略。与用户定义的策略(在应用层中所指定的那些)相反，这些策略(也称为低级策略)在安全系统自身内定义。用户定义的策略可以被转化成一个或多个低级策略，并且可以取决于用户定义的策略的语义来影响一个或多个监视器。

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

在本实施例中，策略不是一体式组件，相反，它们是由可以属于被称为动作模块的一个或多个策略的可重用模块构成的。多个动作模块被关联到唯一的系统调用上并且从进程状态中提取信息，以便提供可以由策略使用的信息以生成决策。与决策点和策略相同，多个动作模块本身提供两个入口点，一个用于进入的系统调用且另一个用于那些退出的系统调用，但是与决策点和策略相反的是，它们对于每一个线程是特定的，所以除了在它们被建立时它们并不需要线程标识符。每一个策略指定针对每一个线程所实例化的并且在被监视的安卓应用(以及子进程)内运行的动作模块列表，其方式为使得无论何时策略入口点被调用，如果针对那个线程的动作模块列表不存在，就要被创建，并且一旦该线程或进程退出，该动作模块列表被移除。通过这种方式，可以独立地跟踪每一个线程执行，并且可以进行附加的安全检查。

在策略入口点被调用时，其将针对生成系统调用的TID循环与那个特定系统调用相关联的所有动作。如果这些动作模块中的任何动作模块认为该系统调用对其而言是有意义的(例如，在某个特定设备上的ioctl()或仅在套接字描述符上的open())，该策略将检查由那些动作模块所生成的数据并且生成决策(安全动作)。然后，该决策被返回至策略决策点，该策略决策点将取决于其他策略结果来决定该决策是否应该被发送回强制执行点。最后，如果决策点已经返回了任何决策，强制执行点将确保进行决策以便强制执行生成该决策的策略。在图6中以图解的方式示出此进程。

安全系统服务

概述

安全系统服务是在应用层中的向Linux层中那些监视器公开所有的安卓框架功能的安卓系统服务。它在启动时运行，在任何用户应用之前。与向其他安卓应用或服务提供服务的正常安卓服务相反，在本实施例中，这种服务并不通过意图动作过滤器或AIDL接口来公开其功能。相反，安全系统服务通过应用层与Linux层之间的通信链路或进程向这些进程监视器提供其功能。在本实施例中，应用层中的安全系统服务与Linux层中的这些进程监视器之间的通信通过请求Unix套接字来发生，即，安全系统服务监听对于TCP端口的请求。这些请求被称为事务。每一个事务具有唯一的ID，并且可以包含零个或更多个由进程监视器设置并且在服务中处理的形参，该服务最终将结果返回给该进程监视器。

每一个事务具有客户端部分(即，进程监视器)以及由安全系统服务所代表的服务器部分。客户端部分设置事务标识符(事务ID)以及这些形参，并且将通过套接字序列化后的它们发送至安全系统服务。事务是同步的，因此，进程监视器被阻止，一直等待到该事务已经被处理。安全系统服务被配置为等待对于安全系统服务套接字的请求。每次接收到新事务，安全系统服务检索事务ID，并且建立事务的服务器部分，该服务器部分从套接字中反序列化出这些形参，并且新事务被放进线程池队列中。一旦有可用的线程处理事务，该事务运行并且执行其功能。它将会返回，并且序列化的结果将被发送至进行请求的进程监视器。为结束进程，进程监视器接收反序列化的事务响应，并且将解除阻止，继续其执行。在本实施例中，通信链路可以使用传输层安全(TLS)，用于保护安全系统服务与这些进程监视器之间的通信的机密性。将认识到，在其他的实现方式中，可以使用其他通信链路或机制来使能安全系统服务器与进程监视器之间的通信，包括但不限于共享存储器空间或类似方式。

在应用层中运行的用于访问安卓框架的那些服务的安全系统服务允许通过标准安卓接口(如例如应用)对每个应用的策略进行规范。同样，它允许这些进程监视器对安卓实现IPC调用的方式进行处理。安全系统服务向这些进程监视器提供至上级安卓服务的入口点，并且在这样做时，进程监视器能够强制执行其策略。以下对这些方面进行进一步的解释。

示例——设置安全策略

参照图7，将通过举例描述示出了安卓设备100上的安全系统服务的功能的安全系统的示例实现方式。安卓设备具有在应用层42中运行的Skype应用102和MyBank应用104，每一个分别具有或被映射至Linux层24中的相应Linux进程106、108。被附加至每一个Linux进程106、108上的分别是相应的进程监视器110、112。Zygote114以及其附加的主监视器116也被示出在Linux层中。安全系统服务120也被示出作为正常的安卓服务在应用层42中运行。举例来说，TCP通信链路被示出在与Skype应用相关联的进程监视器110与安全系统服务118之间，并且类似的通信链路同样存在于或者可以被建立于任何其他的进程监视器与安全系统服务之间。

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

举例来说，MyBank应用104是用户想要保护的敏感应用。用户并不信任Skype应用102通过IPC调用MyBank应用。安全管理员可以限定高级策略，如：Skype不向MyBank授权(Auth)IPC。此策略必须被转化成进程监视器110可以强制执行的低级策略。例如，为了控制应用之间的IPC通信，可以实现低级策略，如：拒绝“CallingAppPackName”所代表的应用与名称为“TargetAppPackName”的应用之间的IPC调用的IPCPolicies。该策略可能是：DenyIPCPolicies(CallingAppPackName，TargetAppPackName，Type)。此策略以调用应用的包名称、目标应用的包名称以及指定该目标是应用还是服务的形参作为实参。对于我们的情况，当附加到Skype上的进程监视器110在初始化时联系安全系统服务120以请求Skype策略时，安全系统服务将从策略数据库中检索相关的策略并且以指定用于Skype、MyBank应用的包名称以及MyBank是应用的那些形参进行回复。然后，进程监视器110可以加载IPC策略如下：DenyIPCPolicies(“com.skype.app”，“com.mybank.app”，APPLICATION)。

监视IPC系统调用

在本实施例中，安全系统服务的其他主要功能是帮助多个进程监视器解决该安全系统服务的附加的被监视进程试图进行通信的应用名称，从而使得该安全系统服务可以然后强制执行关于那个IPC的任何具体策略。在安卓中，IPC调用机制使用特殊类型的消息，用于进行被称为“意图(intent)”的远程方法调用。意图表示对远程过程调用的抽象，并且是Binder管理不同应用之间的IPC的主要方式。这些是安卓中所支持的两种类型的意图：显示意图和隐式意图。显示意图限定哪个应用是意图的接收器。进程监视器可以直接捕获显示意图，并且从正在由被监视进程所执行的相关联的系统调用形参中提取目标应用(或其包名称)。隐式意图指定应该进行的动作，而不是目标应用或服务。然后，由安卓框架负责针对该意图找到最佳匹配目的地。安卓运行时(Androidrun-time)并且具体地活动管理器决定哪个活动将是该意图的目标。活动管理器联系包管理器以解析隐式意图。包管理器是维护关于安卓设备上所安装的那些应用和服务的某些信息的那些系统调用之一。

从进程监视器的角度来看，当它的被监视应用正在使用隐式意图执行IPC系统调用时，进程监视器能够捕获意图并且提取其内容，但是所提取的信息不足以评估其安全策略。IPC安全策略需要作为形参的目标应用，但是隐式意图仅提供对所请求的服务的描述。因为包管理器是在安卓之上的应用层中运行的服务，进程监视器无法直接对其进行访问。然而，进程监视器被配置为用于通过Unix套接字与在应用层上运行的安全系统服务进行交互和通信，并且可以将对指示与隐式意图相关联的目标应用的信息的请求发送至安全系统服务，从而使得它可以强制执行关于那个意图的相关安全策略。

例如，参照图7，假设MyBank应用104具有一种针对“得到某些珍贵之物”所调用的方法“myPrecious”，并且Skype应用102想要将隐式意图发送至具有使用描述“得到某些珍贵之物”的“myPrecious”方法的应用。在安卓中(未安装安全系统)，当Skype应用102通过Binder发送意图时，Binder将向包管理器询问哪个应用具有使用描述“得到某些珍贵之物”的“myPrecious”方法。包管理器将使用MyBank应用104进行回复。因此，Binder将把意图发送至MyBank应用，该MyBank应用将对把珍贵之物给Skype应用102的请求进行回复，这将导致安全问题。在将安全系统安装在安卓设备上时，以上过程如以下所解释的那样发生变化以最小化这种安全风险。

在将安全系统安装在安卓设备上从而使得进程监视器110被附加到Skype应用上时，它将拦截在从Skype应用向Binder发送隐式意图时所生成的系统调用。进程监视器110被配置为用于在意图中检索信息，但是起初进程监视器中的策略无法确定目标应用的包名称，该目标应用的包名称仍然是未知。进程监视器110无法直接访问安卓层中的包管理器，但是安全系统服务120可以，因为它是在具有用于这些进程监视器的特殊通信链路(即，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)，如稍后将解释的。当进程304调用函数调用306时，动态链接符号调用306被代理函数库302拦截，而不是如之前参照图2所描述的那样直接到共享库308。此代理函数库302或拦截模块提供了定制版本的动态链接符号，这些动态链接符号将调用或函数调用重定向至与进程304相关联的监视实体310(如312处所示)。此定制版本的这些动态链接符号具有与它们旨在拦截的实际符号完全相同的签名(并且可以具有相同的名称)。

为清晰起见，图8将监视实体310示出为与其相关联的进程304分开的模块，然而，在本第二实施例中，监视实体310是在进程304内提供或运行的嵌入式方法或函数。基于针对进程304在监视实体310内所配置的该一个或多个安全策略，监视实体310对所检测到的函数调用实现安全动作或决策。举例来说，监视实体可以允许、拒绝或修改函数调用的执行，或完全取消进行函数调用的被监视进程304。如果执行被允许(以其原始或修改形式)，那么，监视实体将实际函数调用(以其原始或修改形式)转发至包含原始符号308的实际共享对象库，如314处所示。此后，使用共享对象库308来照常进行函数以及其可能内部地调用的任何系统调用的执行，该共享对象库在系统调用网关316上进行实际调用，如在318处所示并且如之前参照图2所描述的那样。如果执行被拒绝，监视实体将禁用对符号的调用以防止函数调用执行，并且可以取决于有待调用的相关联的系统调用的性质和/或与进程相关联的安全策略来任选地执行其他附加的安全动作，如取消整个进程或向进程返回值或错误代码以防止如之前关于第一实施例安全系统所讨论的崩溃。

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

第一种形式——LD_PRELOAD变量

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

在这种形式下，LD_PRELOAD方式仅在启动进程时有效。一旦在执行中，如果进程从任何共享对象中加载新符号，LD_PRELOAD设置将不会影响新加载的这些符号。具体地，来自共享对象的被加载的代码可以绕过代理函数库302直接调用对共享对象库308的函数调用。

第二种形式——PLT/GOT插入

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

在安卓中，使用标准NDK工具链编译的所有二进制并且具体地负责启动Zygote母进程(/system/bin/app_process)的二进制被链接至Bioniclibc库308(在图8中示出)。与普通的Linux发行版相反，这个库是动态链接的，并且其代码一旦被加载到存储器中则由所有正在运行的应用所共享。参照图9A，将进一步描述PLT/GOT间接机制。共享对象(或共享库)是一种特殊类型的文件，其结构由可执行可链接格式(ELF)328所定义。在执行期间，由应用代码331进行的对共享对象所提供的符号的调用被转化为到过程链接表(PLT)330(数据结构被定义为ELF规范的一部分)内的条目的跳转指令。这个PLT330的这些条目是桩函数，这些桩函数在被调用时进行到全局偏移表(GOT)334(同样由ELF规范所定义)内的条目的跳转指令333。最后，GOT334中的这些条目是实际符号所驻留的存储器中加载的共享对象的代码337中那些目标符号的实地址335。

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

在本实施例中，安全系统被配置为用于通过使用指向POT340中的包裹函数345的地址改变GOT334中的原始地址来修改GOT的条目。原始地址作为函数指针341存储在POT340中。函数指针341具有与原始函数相同的签名：它不带任何实参，并且返回整数。POT中的将要从GOT334中调用的条目也具有与原始函数相同的签名。当应用331调用此函数func时，POT340中的包裹函数将执行以下步骤。首先，它将在监视实体310中调用PEP339方法进入(enter)343。此enter方法通知PEP339应用331将会执行函数func的调用(注意，调用尚未执行)。PEP339将采用函数以及这些函数形参的名称(在此示例中，func不带有任何形参)。PEP339将此信息传递至监视实体310中的其他模块以决定安全动作。

在评估监视实体内或由监视实体所访问的策略之后，如果PEP339返回343‘允许’，那么函数func可以被执行347。在此示例中，函数func返回整数。在函数返回之后，安全系统被配置为用于在函数已经完成其执行并且返回其值之后进行第二次检查。这使得监视实体能够检查并且修改函数的返回值，如果针对调用函数的应用331所设置的安全策略要求的话。例如，监视实体可以移除某些敏感信息或数据，或用伪值修改这个或这些返回值。此第二次检查通过调用监视实体310内的PEP方法退出(exit)349并且提供函数所返回的值作为实参来进行。

如果安全策略显示不应该允许应用331调用函数func，PEP339的enter方法还可以返回‘拒绝’值342。在这种情况下，将函数特定错误代码344返回至应用331。替代性地，PEP339的enter方法可以返回决策以‘取消’346应用。在这种情况下，包裹函数345将进行终止进程及其应用的退出。

GOT被填充的方式取决于程序(即，操作系统和/或应用)的编译设置。默认地，使用延迟加载方式来填充这些GOT条目。进程第一次调用动态链接符号，在GOT中解析并且插入函数的实际地址。这意味着GOT的存储页面需要在运行时修改。另一个可选项是重定位只读(RELRO)。这个选项指定运行时链接器必须在进程的加载时间期间解析GOT中的所有相关性。这个选项还包括在运行时期间修改这些GOT存储页面，虽然这些修改仅仅在加载时间完成。最后，存在FULLRELRO选项，该选项进行与RELRO相同的操作，但是一旦GOT被填充，这些存储页面被设置为只读。这意味着只有进程本身可以改变这些条目。举例来说，安卓果冻豆(JellyBean)(4.1版)谷歌利用FULLRELRO选项用于编译安卓和系统应用代码。

在第二种形式下，POT340代表拦截动态链接符号调用并将其从其相关联的进程重定向至嵌入式监视实体310的代理函数库302。在一个示例中，安全系统被配置为用于注入对在每一个新启动的进程中的GOT条目进行修改的代码。由于监视实体运行在相同的进程中，通过使用系统调用mprotect()，安全系统可以设置GOT334的存储页面为可写的，进行修改并且然后执行mprotect()系统调用以便如在FULLRELRO中所使用的那样将许可设置回为只读。

在另一个示例中，安全系统可以利用Libhijack(其是C库)以在执行时间期间将用于修改GOT条目的代码注入每一个新重新启动的进程。具体地，安全系统可以利用Libhijack以修改目标进程的GOT条目以重定向函数调用。Libhijack利用ptrace系统调用来修改目标进程的那些存储页面。然而，由于Libhijack是基于ptrace的，其不能在使用FULLRELRO选项(如安卓果冻豆)时使用。

第三种形式——结合LD_PRELOAD变量与PLT/GOT插入的混合FCI机制

在第三种形式下，安全系统实现结合LD_PRELOAD的简单性与PLT/GOT注入的鲁棒性的混合方式以实现FCI机制。在这第三种方式下，安全系统利用母进程Zygote来配置和实现FCI机制，如以下将进一步解释的。

参照图10，首先，修改init.rc文件以针对母Zygote进程设置LD_PRELOAD的值，以指向代理函数库302a。由于安全系统初始仅对监视Zygote对fork()系统调用的调用感兴趣，安全系统在Zygote进程中针对fork()创建一个单一代理函数。当从Zygote350中分支出351进程时，将调用放置在代理函数库302a中的具有与原始fork()函数相同的签名和名称的fork代理函数。这个修改过的fork代理函数将只转发352调用至libc库308中的实fork函数以产生新的子进程353。在创建子进程353时，其将是父进程(即Zygote350)的精确复本或克隆354。这意味着，同样，Zygote的库将会被拷贝到新的子进程353中。具体地，修改过的LD_PRELOAD设置也将对子进程有效，从而使得它指向其自身的代理函数库302b。当内核308完成fork时，其向父Zygote350和子进程353返回值。然而，在返回至实际进程之前，libc库308将经历两个进程的代理函数库302a、302b。针对Zygote进程350的fork()代理函数302a将仅返回355、356而不做任何修改。然而，子进程353的代理函数库302b将在返回358、359之前使用上述mprotect()系统调用方式来进行对GOT条目357的修改。从现在开始，由子进程353所执行的任何函数调用将由修改过的GOT条目拦截。

当新进程353特殊化为预期的应用时，嵌入式进程监视方法(监视实体)将针对应用链接或加载适当的安全策略。如先前所提及的，与进程监视器是附加至其目标进程上的单独进程的第一实施例安全系统相反，监视实体被嵌入到其所监视的相同进程中或者是该进程的一部分。在这个第二实施例中，嵌入式进程监视方法可以访问新进程所特殊化为的应用的包名称，并且因此可以用类似于先前关于第一实施例安全系统所描述的方式来检索适当的安全策略。

在这种形式下，通过PLT/GOT修改来实现针对新进程353的FCI机制的主要优点是：即使子进程将外部库加载为共享对象，PLT/GOT修改仍将是有效的。对于仅使用LD_PRELOAD(如在第一种形式下)来说则不然。因为系统仅仅对拦截来自主Zygote可执行代码(而不是来自其所使用的其他共享对象)的fork()符号调用感兴趣，使用LD_PRELOADFCI机制是足够的。

如果新进程353调用fork以开始新的子进程，所有的GOT修改都将被拷贝至子进程存储器中。因此，子进程将具有带有其自身的代理函数库的嵌入式FCI机制，并且也将由其自身的嵌入式进程监视方法所监视。

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

为在安卓中部署安全系统，将在安全系统共享对象中对安全系统代码进行编译。共享对象将被部署在库在安卓中所在的标准文件夹/system/lib或/vendor/lib中。替代性地，安全系统代码可以被部署在任何其他文件夹中。

为使能安全系统，改变init.rc文件以设置环境变量LD_PRELOAD来指向安全系统共享对象。当在引导时间启动Zygote时，运行时链接器将在任何其他库之前加载安全系统共享对象。以此方式，当Zygote执行fork时，将调用针对fork()符号的代理函数，而不是由Bioniclibc所提供的实际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提供的并且是动态链接的。安全系统为这个符号提供代理函数，这意味着它可以控制在运行时加载哪些共享对象。对于内联汇编码而言，安全系统可以被配置为用于解析不信任的本地代码来检测生成硬件中断的指令，以改变为管理模式(ARM上的SWI#0)。

在上述两种情况下，安全系统都可以被动态切换至使用SCI机制(如ptrace())，如对第一实施例安全系统所完成的那样。举例来说，参照图11，当进程370调用dlopen函数调用371时，安全系统在其代理函数库372中拦截带有dlopen代理函数的函数调用。dlopen代理函数将被配置为用于分支出新进程，该新进程是包括代理函数库376的运行进程370的精确克隆377。

当fork在克隆的进程376上返回378时，克隆的代理函数库376将禁用代理函数库并且调用带有选项PTRACE_TRACEME的ptrace系统调用379。这个选项告诉内核子进程375想要被另一个进程370监视。子进程375还发出有待停止直至父进程370允许它恢复其执行的SIGSTOP380。当子进程375恢复其执行时，它将继续dlopen384操作，并且共享对象(新的本地代码)将被加载至其映像，从而使得其符号可由进程访问。

另一方面，监视父进程还将禁用代理函数库372，并且通过调用带有选项PTRACE_SYSCALL382的ptrace，监视父进程将递送用于使新进程375继续其执行直至其下一个系统调用的信号383。

然后，父进程中的监视实体可以基于与父进程相关联的安全策略执行关于所拦截的这些系统调用的安全动作。换言之，父进程370被附加至子进程375上，从而使得该父进程被配置为用于通过ptrace监视由其目标子进程375所进行的系统调用，如在第一实施例安全系统中那样。

在卸载共享对象时，克隆进程375可以被取消，并且主父进程370的执行将通过拦截函数调用的代理函数的FCI机制被恢复至像以前一样。例如，监视实体可以被配置为用于检测对dlclose的调用，以获得共享对象被卸载的通知。

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

概述

将安全策略从安全策略数据库或策略配置源中加载或链接至被附加到对应于新启动的应用的新进程上或嵌入到该新进程中的监视实体涉及获得信息以正确地标识这种进程已经特殊化为的应用。

如前文所讨论的，在常规的Unix和Linux操作系统中，已经提出了安全系统，这些安全系统基于从shell命令行中对新进程直接可用的启动信息将安全策略立即链接至这些新进程，该启动信息包含新启动的应用的应用名称作为实参。参照图12，这种安全系统基于初始启动指令400(例如，那些shell命令行参数)对将该一个或多个安全策略链接至新进程(在402处)所必要的应用标识数据进行链接或检索。这种早期安全策略绑定机制意味着安全策略是在新进程的实际应用代码刚刚开始进行特殊化之前与新启动的应用相关联的。这种方式的主要问题是恶意应用可能通过后期特殊化为与在shell实参中所使用应用不同的应用来欺骗系统：因此，错误的安全策略组可能被关联至新进程。

参照图12，在至少某些实施例中的安全系统使用后期安全策略绑定机制，其中，将一个或多个安全策略链接或关联至新启动的进程被定时或延迟，直至达到预定义的标识阈值或发生了预定义的事件，如至少到新进程被母进程调用404时或之后，如406处所示。例如，直至新进程被调用404时或之后才确定或提取对应于新进程正在特殊化为的应用或应用的类型的应用标识数据(其被用于链接或关联一个或多个正确的安全策略)。在本说明书中，短语“链接”或“关联”安全策略与进程意在指提取新进程将要特殊化为的应用层中的应用的应用标识数据(例如，应用名称、签名或包名称)以便基于该应用标识数据来确定该一个或多个安全策略、和/或对该一个或多个安全策略进行实际配置或将其加载到被附加到或嵌入到新进程中的监视实体中。

在一种形式下，安全策略在新的子进程被分支出404时或者之后不久被链接。在另一种形式下，在新的子进程进行特殊化408时，或者一旦新进程已经被特殊化，安全策略与应用代码相链接。在另一种形式下，在新进程特殊化之后开始执行410所加载的应用代码时或之后，安全策略被链接。在另一种形式下，安全策略仅在达到预定义的标识阈值时被链接，该标识阈值对应于采集或接收足够或充分的数据或证据，该数据或证据表示或确认Linux层中启动的新进程对应于用户想要启动的应用层中的应用。

以上后期安全策略绑定机制可以被应用于或实现于上面在安卓操作系统的上下文中所描述的第一或第二实施例安全系统中的任一个中。另外，这种后期策略绑定机制可以被应用于其他操作系统中，包括Linux或Unix操作系统、iOS或使用母进程启动新进程的任何其他操作系统，如以下将仅通过举例的方式进一步描述的。

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

安卓操作系统

如先前针对第一实施例安全系统所解释的，在新分支出来的子进程的特殊化过程的最后一步期间检索应用标识数据(例如，完整的应用包名称)。具体地，安全系统被配置为依赖于子进程所执行的最后一步，在应用将其应用名称设置在特殊化数据文件中(例如，在/proc文件系统内)时，该子进程特殊化408为该应用。当应用已经特殊化时，其在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中的应用进程上。iOS中的应用以面向对象C语言、C的超集编写。与所有的C程序一样，面向对象C语言程序以主方法开始。这种主方法是针对iOS中的所有应用自动创建的，并且它被放在支持文件组中的单独的main.m文件中。所有的应用具有相同的主方法。每一个主方法调用负责加载特定于正在启动的应用的类的UIApplicationMain方法。

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

main.m文件是编译过的代码，并且有各种方式可以使用修改过的版本对其进行修改或替换。替代性地，安全系统可以被配置为用于使用otool修补应用的可执行文件以分解二进制main.m代码，并且然后使用必要的ARM代码对其进行修补以插入到对安全系统的主监视器代码的调用中。

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

基于Unix的系统概括

通常，后期安全策略绑定机制可以应用于任何基于Unix的系统(包括如以上所提到的安卓、Linux以及iOS)，其中，新进程被创建并且其特殊化应用包名称设置在单独的位置中，该位置可直接(例如，对于安卓或Linux中的/proc)或间接地(例如，对于iOS中的sysctl)由附加到或嵌入到进程中的进程监视器访问。这是因为在基于Unix的系统中，在进程被启动时，其从父进程中分支出来。例如，在LinuxOS的情况下，有称为init的特殊进程，该进程负责通过命令shell来启动任何新进程。当安全系统被部署在Linux中时，主监视器可以被附加至init上，并且任何时刻新进程被分支出来，新的进程监视器将会被附加。然后，使用后期安全策略绑定机制来确定有待链接至新进程并且在被监视进程上强制执行的安全策略。

进程特殊化的示例

在Unix/Linux操作系统中，进程的创建404与其特殊化408是分离的，如图12中所示。进程的创建通过fork系统调用来进行。当进程调用fork时，创建404作为父进程的精确复本的子进程。这两个进程将继续彼此独立地执行。然而，每一个进程必须了解它是子进程还是父进程。这可以通过由fork所返回的值来完成。在父进程中，fork返回新创建的子进程的进程ID(PID)。在子进程中，fork返回0。因为PID0没有被分配给任何进程，子进程知道其是子进程并且其必须进行特殊化。

在安卓中，以一种类似于Unix/Linux的方式创建进程。然而，它们进行特殊化的方式是不同的。在Unix/Linux中，子进程通过从exec族中调用系统调用之一来进行特殊化。当进程调用exec系统调用时，该进程停止执行其当前程序并且开始从头执行新程序。exec系统调用使用程序的名称以及有待传递给程序的那些形参作为实参。存在子进程得到程序要执行或特殊化为的应用名称的若干方式。

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

在一个示例中，程序名称已经硬编码在父进程代码中。在分支出新的子进程之后，子进程将使用名称来通过execvp系统调用对其进行执行。在本示例中，应用标识数据可以在分支之后直接从子进程代码中提取。

从文件中检索应用名称

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

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

在另一个示例中，父进程可以使用进程间通信(IPC)通道(如像Unix套接字一样的套接字)从外部进程中检索命令。在这种情况下，在fork的父分支中打开客户端套接字。当父通过套接字接收到程序名称时，它分支出子进程。在进行分支时，由于程序名称仍然是父进程的复本，其将被包含在子存储器中。

检索被外部进程推送向子进程的应用名称

在另一个示例中，子进程可以被配置为用于打开IPC通道并且等待有待通过该IPC通道提供的程序名称。仅通过举例，子进程可以使用套接字来监听程序名称。在这个示例中，程序名称被推送向子进程。在这种情况下，在fork的子分支中打开客户端套接字。

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

在另一个示例中，子进程可以被配置为用于使用另一个进程建立IPC通道。在本示例中，子进程可以被配置为发送用于从另一个进程中拉取程序名称的请求。在这种情况下，将在fork的子分支中打开客户端套接字。

安卓——应用名称检索

在安卓中，应用通常是编译为字节代码的Java程序，该字节代码在Dalvik虚拟机中执行并且任选地可以通过Java本地接口(JNI)执行放在共享对象中的本地代码。Zygote进程是仅有的能够创建新应用的进程。Zygote从内部Unix套接字中接收命令以分支出新的应用。该命令包含将使用Java反射被加载到子进程的虚拟机中的Java类名称的名称。该类提供有待运行的应用的静态主方法。然而，类名称并不代表该应用的包名称。将从应用的清单文件中检索此信息，并且然后使用如之前所解释的prctl系统调用在/proc文件系统中设置此信息。

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

各种示例表明如何可以在分支出新进程之后并且在进程特殊化为应用期间使用后期安全策略绑定机制将应用特定的安全策略链接至新启动的进程上。

在其他形式下，后期安全策略绑定机制可以延迟链接安全策略，直至进程特殊化之后并且一旦其执行应用代码。在本示例中，后期安全策略绑定机制被配置为用于监视应用代码的执行，表征正在执行的应用的类型，并且链接适合于该确定的应用类型的一个或多个安全策略。举例来说，安全系统可以基于各种进程动作表征应用的类型，包括但不限于：

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

●进程正在尝试访问和/或正在修改什么数据，例如，SMS、电子邮件、帐号信息、图片、视频、密码。

●进程正在尝试与什么其他进程进行通信：访问设备中的其他应用、请求对敏感服务(如拨号器或SMS发送服务)的访问。

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

5.设备硬件配置以及安全系统的安装

如上所述，安全系统的这些实施例可以在任何合适的硬件设备或运行安卓OS或基于Linux的OS或类似的操作系统的系统上实现。参照图13和图14，将描述其上可以运行安全系统的典型智能电话或平板计算机设备的硬件部件的示例，以及安全系统安装过程。

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

为连接至外界并且进行数据通信，设备可以使用或者有线连接614或者其他(无线)连接615。(无线)连接615可以是基于无线电或光的通信。对于无线通信616，使用天线传输和接收无线电信号。这个天线可以是或可以不是嵌入在设备中的。有线或无线连接可以提供联网能力。对于电信签约信息，设备可以使用用户身份模块619，该用户身份模块可以是插入到设备中的卡。用户身份模块619可以通过控制器618与处理器602接口连接。

可以使用操作系统(例如安卓)来使用户控制设备中的硬件与软件。操作系统是包括用于正常安装在永久存储设备603上的处理器602的指令集的软件。在设备运行时，操作系统也可以被(部分地)放置在易失性存储器604中。

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

参照图14，将解释如何将安全系统安装在存储设备603上的示例。典型地，所安装的带有操作系统(O.S.)(如安卓)的存储设备603包含下列分区：引导702、系统703、恢复704、数据705、高速缓存706以及杂项(misc.)707。

第一实施例安全系统安装

为了使用第一实施例来部署安全系统，应该定义下列模块。主监视器二进制应该被放置到设备的引导702分区内。同样，应该修改作为引导702分区的一部分的init.rc708文件，以便修改应该指向监视器二进制位置的“Zygote”服务。为了修改设备的原始引导702分区，应该从设备中拉取出来分区映像。在第二阶段，二进制文件应该被解包，产生内核映像和引导加载器映像。然后，应该通过将主监视器二进制拷贝到引导加载器映像中(通常在/sbin文件夹中)并且修改init.rc708文件以更新“zygote”服务来修补引导加载器映像。一旦被修补，引导加载器可以连同内核映像被重新打包，以生成引导702分区的补丁版本，其应该被推送回到物理设备中。

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

一旦所有的部件都被部署到设备内，设备应该被重新启动以完成进程。一旦设备已经重新启动，安全系统启动并运行。

第二实施例安全系统安装

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

安全系统服务应该被放在系统703分区中。为了做到这一点，应该通过写权限来重新安装系统703分区，从而使得服务包文件可以被拷贝到该分区中(通常到/system/app中)。一旦被拷贝，该分区可以被重新安装回到其只读状态。还应该将代理函数库安装在系统703分区中(通常在/system/lib中)。在安装本地策略配置文件(或策略数据库)的情况下，其将连同安全系统可能需要使用的任何其他数据文件(这可以包括所有系统组件的复本以在OS实现之后重新使能框架)被放在数据705分区中(通常在/data/system中)。任选地，可以将安全系统和/或本地策略配置文件(或策略数据库)的备份存储在恢复分区704中。一旦所有的部件都被部署到设备内，设备应该被重新启动以完成进程。一旦设备已经重新启动，安全系统启动并运行。

6.第三实施例安全系统——谷歌ChromeOS

以上的安全系统实施例还可以适用于/应用于其他基于Linux的操作系统，如谷歌Chrome操作系统(OS)。Chromium项目包括作为谷歌Chrome浏览器背后的开源项目的Chromium；以及作为谷歌ChromeOS背后的开源项目的ChromiumOS。

该两个项目的代码基数的很大一部分是共同的。具体地，ChromiumOS/谷歌ChromeOS是仅执行基于网络的应用的基于Linux的操作系统。这种OS采用极简方式，其中，仅有的驻留在设备中的应用是浏览器(即，谷歌Chrome)、媒体播放器以及文件系统。基本上，基于网络的应用都是在浏览器中执行的。考虑到常用方式(基本上是在浏览器中运行的应用)，在以下的讨论中，我们将使用术语Chromium来指代这两个项目(Chromium和ChromiumOS)。

Chromium背后的主要思想是在功能的不同进程实例中运行。这里我们使用功能(functionality)来指代所下载的访问网页、执行网络应用的代码以及将由Chromium进程渲染和执行的其他代码。

如在图15中所示，Chromium具有主进程800(称为“浏览器”801)，该主进程负责显示用户界面(UI)以及管理执行选项卡(tab)和插件(plug-in)的其他进程802。Tab进程被称为“渲染器”，并且负责使用渲染引擎(如WebKit和Blink)对每一个tab内的功能进行渲染。在此意义上，tab和插件针对运行ChromeOS的设备定义功能。

默认地，Chromium为用户访问的网站的每一个实例创建新的渲染器进程802(每网站实例一进程)。站点被定义为已注册域(如auckland.ac.nz)。这意味着将在不同的进程中执行指向相同的站点的多个tab。另一种模型是每网站一进程，其中，不同的站点将在不同的进程上运行。然而，指向相同站点的多个tab将由同一个进程运行。每tab一进程是另一种模型，其中，每一个tab将由专用进程所渲染。最后，可以在单一进程中执行Chromium。

图15示出了针对每一个功能实例的不同渲染器进程的情况。具体地，每一个在专用渲染器进程802内执行的tab803向用户提供特定功能。例如，Tab1使auckland.ac.nz网页可视化，Tab2使facebook.com网页可视化，并且Tab3执行基于网络的应用。

每一个渲染器进程802执行代码以为用户提供某种功能。这种功能可以是加载HTML页面或执行基于网络的应用。从OS的角度来看，每一个进程802都是主进程800(浏览器)的子进程，并且不知晓每一个渲染器进程所提供的特定功能。然而，OS并不具有每一个渲染器进程的功能的直观视图。换言之，每一个渲染器进程是“不透明”的进程。因此，强制执行特定于每一个渲染器进程的功能的安全策略不是直接的。

通过使渲染器借助进程间通信(IPC)调用805要求主进程800从网络中取得代码来进行在每一个渲染器进程802中加载特定功能。主进程800与所有的渲染器802之间的这个IPC通道是使用由内核所提供的多个接口通过函数调用和系统调用建立的。例如，在Chromium被部署到Linux和MacOSX上时，使用socketpair()函数/系统调用来建立主进程800与渲染器进程802之间的通道。在之前的实施例中所描述的安全系统可以被部署以利用这个通信通道来拦截消息，这些消息指定在每一个渲染器进程中加载的功能并且强制执行特定的安全策略，如以下将要解释的。

图16示出了安全系统如何监视或监视实体如何可以被附加到Chromium中的不同进程上。首先，主监视器810将被附加到主进程800上或嵌入到其内，并且将监视主进程将何时产生新的渲染器进程802。在产生新的渲染器进程802时，新的进程监视器812(或监视实体)将被附加到新的子进程802上，从而使得每一个新进程各自具有其自身的对应的监视实体。Chromium使用与安卓相同的方式使用Zygote进程产生新进程，该Zygote进程将对自身进行分支以创建渲染器进程。

每一个监视实体812都可以拦截其相关联的渲染器进程802进行的系统调用，以与主进程800进行通信并且提取用于标识每一个渲染器正在执行什么功能的信息。这允许安全系统关联为每一个渲染器将要执行的功能量身定制的特定安全策略(从策略数据库中)，即，每一个监视实体检索并强制执行特定于与其进程相对应的应用的安全策略。因此例如，监视渲染器进程1的监视实体812将强制执行特定于域Auckland.ac.nz(Tab1)的安全策略，而监视渲染器进程2的监视实体812将强制执行特定于域Facebook.com(Tab2)的策略。将认识到，主监视器800以及多个进程监视器802可以或者是它们所监视的对应的进程的一部分(例如，嵌入到其中)，在该情况下，使用了FCI技术；或者是附加到它们所监视的对应的进程上的单独的进程，在该情况下，使用了SCI技术，该两种技术在之前的实施例中都进行了描述。

7.分析系统

概述

现在将参照图17至图21对分析系统的实施例进行描述。分析系统是安全专家或系统管理员在各种模式下可使用的概要分析器和/或分析工具。

在一种模式下，该分析系统可用于分析运行时执行的应用以标识恶意/可疑行为。在这种模式下，分析系统可以用于概要分析在给定设备映像(供应商+OS版本)上的应用执行，并且此概要信息可以用于创建定制的安全策略，这些定制的安全策略可以被部署在所概要分析的设备映像上。在这种模式的一种配置中，分析系统在一种单步模式中操作，在该模式中，在检测到所有的或具体的一组由应用所发起的系统调用之后停止或暂停该应用的执行，并且分析系统将这个检测连同指示所检测的系统调用的数据报告或通知给用户并且等待来自用户的安全动作决策，即，是否允许或拒绝执行或如先前关以上安全系统实施例所描述的某种其他的安全动作，并且分析系统基于所决定的安全动作建立定制的安全策略。然后，定制的安全策略可以被部署以在管理员的控制之下在所概要分析的设备或其他设备上运行，其在运行相同的应用的设备上运行相同的应用或应用组。

在另一种模式下，分析系统可以用于策略调试模式或登录模式中，其中，安全系统在设备上运行以对各种执行应用强制执行所配置的安全策略，并且分析系统检索指示应用执行的数据，如强制执行的安全策略所控制的以供用户观看，从而使得可以进行对这些安全策略的细化或改进以提升性能和/或安全性。

分析系统配置

参照图17，分析系统包括安装在运行有待分析的应用的目标设备900上的多个模块以及与设备900进行数据通信904并且为分析提供图形用户界面(GUI)的分析设备902上的一个或多个模块。部署在目标设备900上的这些模块对指示应用的执行的数据进行概要分析或检索，并且然后将所采集的概要信息发送至在分析设备运行的这些模块上以供显示和用户交互。

目标设备900可以是任何具有先前所描述的安全系统可以在其上操作的操作系统的电子设备在本示例中，目标设备900是智能电话，但是它可以替代性地是例如平板计算机、PDA、计算机或运行其上执行应用的操作系统的任何其他设备。分析设备902可以是可以与设备900进行通信的任何其他的电子设备，如台式或膝上型PC、或平板计算机、PDA、智能电话或具有包括显示器以及一个或多个用户输入设备(例如，触摸屏、鼠标、键盘和/或类似设备)的用户接口的任何其他的可编程设备。目标设备900与分析设备902之间的数据通信链路可以是任何合适的有线或无线数据通信链路或介质，如例如可操作地连接这两个设备的USB电缆、或无线数据通信链路(如通过WiFi或蓝牙)、或任何其他合适的数据连接。

目标设备900根据以上所描述的第一或第二实施例中的任一个来操作安全系统。分析系统是这些安全系统模块的扩展，并且在某些特定模式下，分析系统临时控制安全系统的多个方面的操作。基于之前所描述的基于策略的安全系统来配置分析系统。安全系统提供目标设备上的监视基础设施，并且在已经部署安全策略的情况下，安全系统还负责强制执行这些安全策略。

仅通过举例，目标设备900被示出运行两个应用906a、906b。为清晰起见，仅示出了与应用906a、906b中的每一个相关联的安全系统的对应的监视实体908a、908b。这些监视实体如先前所描述的那样操作以监视它们对应的相关联应用，以拦截和/或检测系统调用。具体地，这些监视实体采集指示它们的相关联应用如在912处所示的执行的这些系统调用的细节或数据。系统调用信息通常包括系统调用的名称以及这些系统调用形参的值。分析系统提供了概要分析器模块910a、910b，一个附加到每一个对应的监视实体908a、908b上。概要分析器910a、910b依赖于安全系统的监视实体908a、908b的功能来采集系统调用信息用于分析。概要分析器910a、910b被附加到它们对应的监视实体908a、908b上，并且访问由这些监视实体所接收的系统调用信息，如在914处所示。在本实施例中，修改安全系统的监视实体908a、908b以与分析系统的概要分析器910a、910b进行通信。在单步模式下，这些监视实体直接与它们对应的概要分析器进行通信，绕过安全系统的策略强制执行点(PEP)和策略决策点(PDP)。在策略调试模式下，这些监视实体首先与PEP模块和PDP模块进行通信以根据先前所描述的安全系统来得到并强制执行安全决策，并且然后将此安全决策以及系统调用信息传递给它们对应的概要分析器。在任一种模式下，概要分析器910a、910b然后将此信息转发给分析代理模块918，例如通过进程间通信(IPC)通道，如在916处所示。代理模块918在目标设备上本地维护或存储信息，并且可操作用于将信息发送至分析设备上。

分析系统提供在分析设备902上的分析GUI模块，用户可以与该模块进行交互以取决于分析系统运行什么操作模式来进行先前所描述的各种任务。当分析设备802的分析GUI通过数据通信链路904连接至目标设备上时，代理918使所接收的系统调用信息通过数据通信链路流向分析GUI，以供用户在分析设备902上的后续分析以及交互。例如，将系统调用信息为用户(如系统管理员)显示在分析设备902的显示器上。在本实施例中，分析设备902(例如，PC)上的分析GUI与目标设备900上的代理918之间的数据通信链路904是通过USB电缆并且使用转发安卓调试桥(ADB)的特征的端口进行隧道传送。ADB是一种由安卓SDK所提供的工具。ADB的端口转发仅在PC至设备的方向上工作，意味着只能通过分析设备来发起通信。通过这种配置，分析设备902上的分析GUI从目标设备900上的代理处拉取信息。在替代性的无线数据通信链路配置中，例如可以使用通过WiFi连接在安全外壳(SSH)隧道上进行转发的端口。然而，将认识到，在替代性实施例中，系统可以被配置为用于允许或者目标设备或者分析设备来发起数据通信。

IPC通信规范——数据结构

在本实施例中，概要分析器910a、910b与代理918之间的通信是IPC。现将参照图18至图20来描述在IPC事务中所使用的数据结构。

进程数据数据结构

图18示出了在概要分析器接收到由其相关联的监视实体所检测到的系统调用信息时在概要分析器与目标设备上的代理之间的IPC调用所使用的高层数据结构。主进程数据数据结构920包含进程(执行应用)以及线程的信息，所检测到的系统调用产生自该线程。在本实施例中，进程数据数据结构920包含下列字段：

‐进程ID：执行系统调用的进程的ID；

‐线程ID：执行系统调用的线程的ID；

‐父进程ID：这表示执行系统调用的进程的父进程的ID；

‐包名称：由进程所执行的应用的包名称；

‐系统调用Info：指向系统调用Info数据结构922的指针，带有更多的关于正在被执行的系统调用的信息；以及

‐时间戳：该时间戳用于在将系统调用显示在分析GUI中时根据它们被捕获的时间对它们进行排序。

系统调用Info数据结构

在本实施例中，进程数据数据结构920所指向的系统调用Info数据结构922包含下列字段：

‐标签(Tag)：在系统调用Info被发送至分析GUI之前由代理所分配的唯一标识符——并且稍后将对其进行更详细的解释；

‐进入/退出(Enter/Exit)：这个字段指示系统调用是进入模式还是退出模式；

‐系统调用名称：系统调用的名称；

‐形参：指向形参数据结构924的指针(图19)；以及

‐安全决策：指向安全决策数据结构的指针(图21)——并且稍后将对其进行更详细的解释。

形参数据结构

参照图19，将进一步解释用于本实施例的形参数据结构924。应用所进行的系统调用经常具有指向复杂数据结构的形参指针，该复杂数据结构可能包含指向其他数据结构的指针。为表示这种复杂实参类型，分析系统利用特定的数据结构集合来处理这种情况。形参数据结构924包含一种或多种形参集合数据结构926。在本实施例中，每一种形参集合数据结构926包含下列字段：

‐集合ID：集合的ID；

‐父集合ID：父集合的ID。这可以是0，以防这个形参没有父形参；以及

‐形参i：这是指向表示系统调用的形参的形参数据结构928的指针。

在本实施例中，每一种形参数据结构928包含形参的名称，其类型和值(其也可以是指针)。

形参集合数据结构926中的集合ID和父集合ID的使用允许分析系统使用线性数据结构来表示多级数据结构(如，树)。通过举例，在图20中示出了如何使用形参集合ID和父集合ID来表示树的示例。

安全决策数据结构

安全系统的这些监视实体通过拦截在应用的执行期间进程和线程所进行的系统调用来负责监视应用行为，如之前参照安全系统的实施例所描述的。这是分析系统创建应用概要所需的概要信息，其可以然后用于例如当分析系统在单步模式中操作时配置适当的新的安全策略。

安全系统还负责强制执行安全策略以控制应用的行为。在评估现有的安全策略的性能时，系统管理员可以使用分析系统以获得性能信息，该性能信息是关于在应用的执行期间评估什么策略以及正在强制执行什么决策，例如当分析系统正在策略调试或登录模式下操作时。

分析系统的这些概要分析器可以使用安全系统的安全决策数据结构来从这些监视实体采集此概要和/或性能信息，并且将其传递至分析系统的分析GUI。

参照图21，针对本实施例示出了在安全决策数据结构930中找到的不同数据结构的概图。在本实施例中，安全决策数据结构930包含下列字段：

‐策略1至n：指向策略数据结构932的指针集合。每一个策略表示部署在设备上的策略配置；

‐冲突消解模式：因为针对任何系统调用可以强制执行多种策略，安全系统必须选择一种策略的决策(标识为获胜策略)。为了做到这一点，需要指定冲突消解机制。这个字段提供了关于当做出决策时哪个冲突消解机制合适的信息。

‐获胜策略ID：冲突消解机制从部署在设备内的策略中所选择的策略的ID。

在本实施例中，策略数据结构932包含关于特定策略配置的信息：

‐策略ID：策略的ID；

‐默认结果：这是当没有规则适用时默认做出的决策。这可以是以下结果之一：例如，允许、要求、拒绝和取消；

‐优先级：这个字段提供每一种结果的优先级的排序。这是因为在策略中可能有适用于同一个系统调用的若干规则。将选择具有最高优先级的结果；

‐规则1至n：指向规则数据结构934的指针集合；以及

‐获胜规则ID：针对本系统调用所选择的结果的规则的ID。

在本实施例中，规则数据结构934包含下列字段：

‐规则ID：规则的ID；

‐目标：此规则控制对其进行访问的资源；

‐结果：规则的结果(例如，或者允许、要求、拒绝或取消)；以及

‐附加形参：可选形参。

概要分析器与分析代理之间交换信息

概要分析器910a、910b采集系统调用信息并且还有转发自监视实体908a、908b的指示如果在策略调试模式下操作所强制执行的安全决策的信息，创建进程数据数据结构920并且将其发送至分析代理918。在本实施例中，此数据通信是使用例如以下API通过IPC通道实现的：决策通知(ProcessData数据)。例如，在监视实体检测到或拦截到系统调用时，概要分析器使用其相关联的监视实体所提供的数据来填充进程数据数据结构。在此之后，概要分析器调用通知API来将数据发送给分析代理。如果在单步模式下，分析代理然后检索安全决策(例如，从分析设备上的分析GUI中)，并且以该安全决策进行回复，该安全决策然后被概要分析器传递回监视实体进行强制执行。分析代理的操作取决于其在什么模式下操作。

当分析系统不是活跃的(即，目标设备没有与分析设备进行数据通信，或分析GUI没有被发起)，目标设备上的安全系统基于配置的安全策略如之前在第一和第二实施例中所描述的那样工作，其中，监视实体强制执行由PEP模块和PDP模块所确定的安全决策。当分析系统是活跃的，将信号或指令通过分析代理发送给这些监视实体，以对这些监视实体进行重新配置或指示以便转发所检测到的系统调用信息，以及如果在策略调试模式下操作)，将所强制执行的安全决策发送至它们对应的概要分析器中。这还意味着对这些监视实体的操作进行修改从而使得这些监视实体所强制执行的安全动作或决策是由分析系统控制的(至少当在单步模式下时)。在任一种模式下，为进行概要分析和/或性能分析，系统管理员可以实时地观看指示应用执行(例如，系统调用)的信息以及任何正在被强制执行的配置安全策略。

如果分析系统在登录或策略调试模式下操作以评估所配置的安全策略的性能，这些监视实体被配置为用于使用PEP模块和PDP模块来如它们通常进行的那样强制执行所配置的安全策略。然而，另外，分析代理将关于所拦截的系统调用的采集信息和来自这些概要分析器的产生的安全决策转发至分析设备上的分析GUI，以供例如系统管理员进行观看和分析，从而使得他们可以评估所配置的安全策略的性能。

替代性地，如果分析系统在单步模式下操作，用于分析应用并配置新的安全策略，这些监视实体被配置为用于遵从分析代理以强制执行安全决策。分析代理通过其对应的概要分析器返回给监视实体的安全决策是由操作该分析GUI的系统管理员所指定的决策(例如，安全动作，如允许、要求、拒绝和取消)。例如，由目标设备的分析代理通过数据通信链路将表示由在目标设备上执行的应用所发起的系统调用的系统调用信息发送至分析设备的分析GUI。然后将所接收到的信息呈现给系统管理员，并且系统管理员可以然后选择安全动作，如但不限于允许、要求、拒绝或取消。然后该分析GUI将所选择的决策返回给目标设备上的分析代理，该分析代理将其转发至相关概要分析器。然后，概要分析器将决策转发至其相关联的监控实体进行强制执行。另外，将由系统管理员进行的所选择的安全决策存储在一个或多个策略文件中。随着应用继续执行，这个进程继续，并且系统管理员逐渐针对目标设备建立一个或多个定制的安全策略。然后，在正常设备操作期间，可以由安全系统将这些定制的策略部署或推送给目标设备或由系统管理员所控制的特定用户群组中的一个或多个类似目标设备的群组进行强制执行。

将信息从分析代理中拉取至分析GUI

在本实施例中，由于在ADB中进行转发的端口工作的方式，分析GUI从分析代理处采集所描述的信息。在某些配置下，分析代理可操作用于提供缓冲。具体地，分析代理可以提供缓冲器以捕获数据，该数据是在这些概要分析器开始通知代理所拦截系统调用之后但是在分析GUI请求信息之前所产生的。

在本实施例中，分析设备902上的分析GUI以及分析设备900上的分析代理使用以下API通过数据通信链路904交换信息：

‐responsestart(mode)(响应开始(模式))——此命令告诉分析代理开始从这些概要分析器中采集信息。该形参模式表示所选择的分析系统工作的方式(或者登录模式或者单步模式)。response(响应)是或者成功或者失败。如果成功，那么分析代理开始采集信息。

‐voidstop()——此命令停止分析代理采集进一步的信息。

‐getCallInfo()——此命令允许分析GUI从分析代理中请求系统调用信息。分析代理在发送开始命令之后缓冲信息。然后，当分析GUI进行此调用时，由分析代理缓冲直到该实例的信息通过数据通信链路被推送至分析GUI。

‐decision(tag,userDecisio)——在单步模式下操作时，分析GUI使用这个命令通知分析代理用户关于给定的系统调用已经选择的决策。分析代理使用标签来标识该决策是针对哪个系统调用的。

‐flush()——此命令告诉分析代理排出所有存储在缓冲器中的数据。

‐getPolicies()——此命令允许分析GUI得到安装在目标设备上的策略配置。此命令将文件描述符返回至文件配置保存的位置(例如，/data/.securitysystem/rules.json)。

‐ps()——此命令允许分析GUI得到在目标设备上运行的进程的列表(程序名称和PID)。

分析系统的应用

如上所述，取决于用户(例如，系统管理员或与目标设备相关联的用户)的目的，分析系统可以在各种模式下操作。例如，系统可以用于以下各项中的任何一项或多项：

●进行对应用运行时行为(访问资源及其他应用)的分析，

●作为概要分析器从进程执行中提取信息，

●作为针对恶意/可疑代码的分析系统，和/或

●作为安全课程中的教学辅助，以向学生演示恶意软件如何运行。

分析系统的优点

分析系统的某些实施例较现有的调试器或系统提供了以下益处和/或优点：

●分析系统并不要求来自特殊化的内核层模块(如Linux中的Audit系统)的支持。安全系统采集所有的对于分析系统是透明的所需的信息。这还意味着分析系统可以在其他操作系统(如iOS和Windows)上、或其他任何可以部署安全系统的操作系统平台上实现。

●分析系统可以在默认不使能或存在特殊化的内核层模块(如Audit)的设备上工作。例如，安卓设备中存在的内核的版本通常是用于台式计算机的内核发行版的简化版本。这意味着内核模块(如Audit)默认不存在。所描述的分析系统并不要求来自此类模块的支持，因此可以在此类安卓设备上操作。

●与调试器相比，分析提供提供了某些优点。首先，调试器依赖于有待使用被使能能够采集有意义信息(如系统调用的形参)的特殊标记来进行编译的库。出于性能原因，设备上所部署的这些库默认禁用调试符号。为使能这些调试符号，用户必须使用编译特殊标记对这些库进行重新编译，并且在设备内对它们进行重新部署。第二，调试器经常依赖于工具，如ptrace，其因为用户与内核空间之间所需要的上下文切换而引入高罚分。至少分析系统的某些实施例并不要求使用特殊标记对库进行编译或使用工具(如ptrace)。

8.概述

分析系统的实施例可以通过硬件、软件、固件、中间件、微代码或其任何组合来实现。当以软件、固件、中间件或微代码实现时，用于进行所需的任务的程序代码或者代码段可以存储在诸如存储介质或其他存储设备的机器可读介质中。处理器可以进行所需的任务。代码段可以表示流程、函数、子程序、程序、例程、子例程、模块、软件包、类或指令、数据结构或程序语句的任何组合。代码段可以通过传递和/或接收信息、数据、实参、形参或存储器内容来耦合到其他代码段或硬件电路上。信息、实参、形参、数据等可以通过任何合适的方式(包括存储器共享、消息传递、令牌传送、网络传输等)被传递、转发或传输。

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

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

结合在此所披露的示例描述的方法或算法可以直接地在硬件中、在可由处理器执行的软件模块中、或者两者的组合中以处理单元、编程指令或其他指示的形式来体现，并且可以包含在单个设备中或分布在多个设备上。软件模块可以驻留于RAM存储器、闪速存储器、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移除磁盘、CD-ROM或本领域已知的任何其他形式的存储介质。存储介质可以被耦合至处理器，这样使得处理器可以从存储介质读取信息并将信息写至其中。在替代方案中，可以将存储介质整合至处理器。

可以将附图中所展示的这些部件和功能中的一个或多个重新排列和/或组合为单个部件或体现为若干部件，而不脱离本披露的范围。还可以添加附加的元件或部件，而不脱离本披露的范围。另外，可以在软件、硬件或其组合中实现在此所描述的特征。

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

前文对本主题的描述包括其各种形式。可以对其进行修改，而不脱离本披露的范围。

Claims (32)

1.一种用于分析在目标设备上执行的应用的分析系统，该系统包括：

在该目标设备上运行的分析代理，该分析代理被配置为用于对指示在执行期间由多个应用所发起的多个系统调用的信息进行接收或检索；以及

通过数据通信链路与该目标设备进行数据通信的分析设备，该分析设备被配置为用于通过该数据通信链路从该目标设备的该分析代理接收该信息，并且其中，该分析设备包括被配置为用于显示所接收的该信息以供用户观看和/或交互的分析图形用户界面(GUI)。

2.根据权利要求1所述的分析系统，其中，该目标设备进一步包括与每一个执行应用相关联的监视实体，其中，每一个监视实体被配置为用于直接或间接地检测由该相关联的执行应用所进行的多个系统调用。

3.根据权利要求2所述的分析系统，其中，每一个监视实体被配置为用于通过拦截对该目标设备的操作系统的内核的系统调用来检测这些系统调用。

4.根据权利要求2所述的分析系统，其中，每一个监视实体被配置为用于通过拦截多个共享或动态库符号调用来检测多个系统调用，这些共享或动态库符号调用旨在调用对该目标设备的操作系统的内核的一个或多个系统调用。

5.根据权利要求2所述的分析系统，其中，每一个监视实体将多个系统调用直接或间接地转发至该目标设备的该分析代理。

6.根据权利要求5所述的分析系统，其中，每一个监视实体包括相关联的概要分析器，该概要分析器被配置为用于对指示由其相关联的监视实体所检测到的系统调用的信息进行检索或接收并且将该信息转发至该分析代理。

7.根据权利要求6所述的分析系统，其中，该目标设备的这些概要分析器被配置为用于通过进程间通信通道(IPC)向该分析代理发送信息或从该分析代理接收信息。

8.根据权利要求6所述的分析系统，其中，每一个监视实体被配置为用于在检测到系统调用时停止或暂停其相关联的应用的执行，并且等待用于强制执行的安全决策，该安全决策是关于如何处理所检测到的该系统调用的执行的指令。

9.根据权利要求8所述的分析系统，其中，该安全决策是以下各项中的任何一项：允许执行该系统调用、拒绝执行该系统调用、修改该系统调用、或取消该应用执行。

10.根据权利要求8所述的分析系统，其中，该目标设备的该分析代理被配置为用于将指示所检测到的该一个或多个系统调用的该信息转发至该分析设备，并且基于该分析设备的该GUI中的用户输入针对该分析代理生成安全决策，所生成的安全决策通过该分析的对应的概要分析器被发送回该分析代理进行强制执行，该分析代理被配置为用于将该决策转发至相关监视实体。

11.根据权利要求10所述的分析系统，其中，对该分析设备所作出的这些安全决策被存储在安全策略文件内。

12.根据权利要求6所述的分析系统，其中，这些监视实体是安全系统的多个组件，在该安全系统内这些监视实体响应于所检测到的多个系统调用基于该安全系统可访问的一个或多个安全策略强制执行多个安全决策。

13.根据权利要求12所述的分析系统，其中，每一个监视实体被配置为用于基于该安全系统的该一个或多个安全策略来为所检测到的系统调用检索并强制执行该安全决策，并且然后将指示所检测到的该系统调用的信息以及所强制执行的多个安全决策通过其对应的概要分析器转发至该分析代理，其中，该分析代理被配置为用于将该信息转发至该分析设备，以供用户通过该分析设备的该GUI进行分析。

14.根据权利要求6所述的分析系统，其中，该目标设备的该分析代理被配置为用于在将接收自这些概要分析器的信息发送到该分析设备之前将其存储在缓冲器内。

15.根据权利要求14所述的分析系统，其中，该目标设备的该分析代理在通过该数据通信链路从该分析设备接收到请求指令时使所存储的该缓冲信息流至或者发送至该分析设备。

16.根据权利要求1至15中任一项所述的分析系统，其中，该目标设备的该分析代理被配置为用于响应于通过该数据通信链路从该分析设备接收到开始指令而开始对指示由在该目标设备上所执行的多个应用进行的多个系统调用的信息进行接收或检索。

17.根据权利要求1至16中任一项所述的分析系统，其中，该目标设备的该分析代理被配置为用于响应于通过该数据通信链路从该分析设备接收到停止指令而停止对指示这些系统调用的信息进行接收或检索。

18.根据权利要求1至17中任一项所述的分析系统，其中，该目标设备是具有能够执行多个应用的操作系统的可编程设备，并且该分析设备是具有用于该分析GUI以及一个或多个用户输入设备的相关联的显示器的可编程设备。

19.根据权利要求1至18中任一项所述的分析系统，其中，该目标设备包括基于Linux的内核以及由与该内核相关联的Linux层以及包括多个应用的高级的应用层所限定的系统架构。

20.根据权利要求1至18中任一项所述的分析系统，其中，该目标设备包括包含内核空间和用户空间的架构，其中，该内核空间包括类Unix内核，并且该用户空间包括这些应用。

21.一种通过显示在通过数据通信链路与目标设备进行数据通信的分析设备上的分析图形用户界面(GUI)来分析在该目标设备上执行的多个应用的方法，该方法包括：

通过该数据通信链路将请求指令发送至该目标设备的分析代理，以请求指示在执行期间由这些应用所发起的多个系统调用的信息；

在该分析设备处通过该数据通信链路从该分析代理接收所请求的该信息；以及

在该分析GUI上向用户显示所请求的该信息。

22.根据权利要求21所述的方法，其中，该方法进一步包括针对该目标设备上的该分析代理生成开始指令，以发起该分析代理对指示所检测到的在执行期间由多个应用发起的多个系统调用的信息进行接收或检索。

23.根据权利要求22所述的方法，其中，该开始指令是通过该数据通信链路生成并且发送至该分析代理的命令。

24.根据权利要求21至23中任一项所述的方法，其中，该方法进一步包括响应于用户输入而针对所检测到的系统调用生成安全决策，并且将所生成的该安全决策通过该数据通信链路发送至该目标设备的该分析代理，以对所检测到的该系统调用进行强制执行。

25.根据权利要求24所述的方法，其中，该方法进一步包括将所生成的每一个安全决策存储在一个或多个安全策略文件中，以针对该目标设备生成一个或多个定制的安全策略。

26.根据权利要求21至23中任一项所述的方法，其中，该方法进一步包括对指示由在该目标设备上运行的安全系统响应于所检测到的多个系统调用而强制执行的安全决策的信息进行请求。

27.一种用于显示在通过数据通信链路与目标设备进行数据通信的分析设备上的分析图形用户界面(GUI)的分析在该目标设备上执行的多个应用的方法，该方法包括：

在该目标设备处直接或间接地从与每一个执行应用相关联的多个监视实体接收或检索指示所检测到的在执行期间由多个应用发起的多个系统调用的信息；

在该目标设备处通过该数据通信链路从该分析设备接收请求指令，该请求指令针对指示在执行期间由这些应用发起的这些系统调用的该信息；以及

将所请求的该信息通过该数据通信链路发送至该分析设备。

28.根据权利要求27所述的方法，其中，该方法进一步包括响应于接收到开始指令而对指示在执行期间由多个应用所发起的多个系统调用的信息进行接收或检索。

29.根据权利要求27或权利要求28所述的方法，进一步包括在检测到系统调用时暂停应用的操作、并且等待关于如何处理所检测到的该系统调用的执行的安全决策。

30.根据权利要求29所述的方法，包括通过该数据通信链路从该分析设备接收该安全决策、并且将所接收的该安全决策发送至与该安全决策所涉及的被暂停的该应用相关联的监视实体进行强制执行。

31.根据权利要求29所述的方法，其中，该方法包括基于与该应用相关的一个或多个安全策略来生成该安全决策、并且将所生成的该安全决策发送至与该安全决策所涉及的被暂停的该应用相关联的监视实体进行强制执行。

32.根据权利要求31所述的方法，其中，该方法进一步包括通过该数据通信链路将指示针对所检测到的多个系统调用的所生成的这些安全决策的信息与指示所检测到的这些系统调用的信息一起发送至该分析设备。