CN108090361B - 安全策略更新方法及装置 - Google Patents

Abstract

本发明公开了一种安全策略更新方法及装置，属于计算机技术领域。该方法包括：获取安全策略文件的补丁文件；将所述安全策略文件从内核空间读取到用户空间；根据所述补丁文件在所述用户空间更新所述安全策略文件，得到更新后的安全策略文件；将所述更新后的安全策略文件从所述用户空间写回所述内核空间。本发明解决了现有技术中由于只有发布安全策略文件的源代码的开发者才能编写更新后的安全策略文件，导致的安全策略文件更新不及时的问题；实现了不具有源代码获取能力的开发者也可以对移动终端中的安全策略文件进行更新，达到了提高更新安全策略文件的及时性的效果。

Description

安全策略更新方法及装置

技术领域

本发明实施例涉及计算机技术领域，特别涉及一种安全策略更新方法及装置。

背景技术

Android(安卓)是一种基于Linux的开放源代码的操作系统。目前，Android系统广泛应用于移动终端中。为了增强Android系统的安全性，NSA(The National SecurityAgency，美国国家安全局)将SELinux(Security-Enhanced Linux)移植到Android系统，形成了SEAndroid(Security-Enhanced Android)。SEAndroid的安全机制的核心之一是在操作系统中预先设置安全策略文件，该安全策略文件包括多条安全策略。随着操作系统中运行的应用程序越来越多，移动终端当前使用的安全策略文件可能不包括一些恶意进程对应的安全策略，此时，需要更新移动终端中的安全策略文件，以限制恶意进程的访问。

相关技术中在更新移动终端中的安全策略文件时，所采用的方法包括：开发者获取整个安全策略文件的源代码；修改该安全策略文件，得到更新后的安全策略文件；将该更新后的安全策略文件上传至服务器。移动终端中安装的策略更新应用检测到服务器中的安全策略文件发生更新后，从服务器中获取更新后的安全策略文件，并利用更新后的安全策略文件覆盖移动终端的文件系统中原始的安全策略文件。当移动终端中的操作系统再次启动时，会将文件系统中的更新后的安全策略文件加载到内核空间中，以使得移动终端可以根据更新后的安全策略文件中的安全策略，在内核空间运行限制恶意进程的非法访问。

由于只有发布安全策略文件的源代码的开发者才能获取到该源代码，而上述方法中对安全策略文件的修改需要基于该源代码来进行，由此可知，只有发布安全策略文件的源代码的开发者才能对安全策略文件进行修改。在这种情况下，当其它开发者发现原始的安全策略文件存在漏洞，而发布源代码的开发者未发现该漏洞时，就会造成更新移动终端中的安全策略文件不够及时，导致移动终端的操作系统的安全性降低的问题。

发明内容

为了解决现有技术中只有发布安全策略文件的源代码的开发者才能编写更新后的安全策略文件，导致的安全策略文件更新不及时的问题，本发明实施例提供了一种安全策略更新方法及装置。所述技术方案如下：

第一方面，提供了一种安全策略更新方法，所述方法包括：

获取安全策略文件的补丁文件；

将所述安全策略文件从内核空间读取到用户空间；其中，所述内核空间是指虚拟内存中用于运行内核及驱动程序的区块，所述用户空间是指所述虚拟内存中用于运行应用程序的区块；

根据所述补丁文件在所述用户空间更新所述安全策略文件，得到更新后的安全策略文件；

将所述更新后的安全策略文件从所述用户空间写回所述内核空间。

第二方面，提供了一种安全策略更新装置，所述装置包括：

获取模块，用于获取安全策略文件的补丁文件；

读取模块，用于将所述安全策略文件从内核空间读取到用户空间；所述内核空间是指虚拟内存中用于运行内核及驱动程序的区块，所述用户空间是指所述虚拟内存中用于运行应用程序的区块；

更新模块，用于根据所述补丁文件在所述用户空间更新所述安全策略文件，得到更新后的安全策略文件；

写回模块，用于将所述更新后的安全策略文件从所述用户空间写回所述内核空间。

本发明实施例提供的技术方案带来的有益效果包括：

通过将安全策略文件从内核空间读取到用户空间，使用补丁文件对用户空间中的安全策略文件进行更新，使得开发者无需获取到安全策略文件的源代码，仅需要编译待更新的安全策略并生成补丁文件，即可使用补丁文件在用户空间中实现对移动终端中的安全策略文件的源代码进行更新，这样不具有源代码获取能力的开发者也可以对移动终端中的安全策略文件进行更新，既提高了安全策略更新方法的通用性，也提高了更新安全策略文件的及时性。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本发明一个实施例提供的安全策略更新方法的流程图；

图2是本发明另一个实施例提供的安全策略更新方法的流程图；

图3是本发明另一个实施例提供的安全策略更新方法的流程图；

图4是本发明另一个实施例提供的安全策略更新方法的流程图；

图5是本发明一个实施例提供的安全策略更新装置的框图；

图6是本发明一个实施例提供的移动终端的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

为了方便理解，先对本发明实施例提及的若干个名词分别作简单介绍，具体如下：

安全上下文(又称为域)：是一个附加在主体和客体上的标签，其中，主体是访问客体的进程，客体是系统中的一类实体，比如：进程、文件、系统属性等。在SEAndroid中，每个进程或文件对应一个安全上下文，该安全上下文实际上是一串字符串，通常由四部分内容组成，分别为：SELinux用户、SELinux角色、类型和安全级别。不同部分之间通过冒号来分隔，格式为：user(用户)：role(角色)：type(类型)：sensitivity(安全级别)。作为一个示意性的例子：init进程的安全上下文的格式为：u：r：init：s0。又例如：系统文件/system/bin/toolbox的安全上下文为：u：object_r：system_file：s0。

在SEAndroid中，user有且只有一种：格式为u；role存在两种，用于表示进程的格式为r的role，以及，用于表示文件的格式为object_r的role；type用于定义主体和客体所属的类型；sensitivity由sensitivity和category(类别)两部分组成，格式为sensitivity[:category_set]，其中，category_set是可选的，例如，定义了s0和s1两个sensitivity，以及c0、c1和c2三个category，那么“s0:c0,c1”表示的就是sensitivity为s0、category为c0和c1的一个安全级别。

安全策略文件：用于存储至少一条安全策略，每条安全策略用于定义移动终端中一个安全上下文对另一个安全上下文的访问权限，或者，一个安全上下文切换后的另一个安全上下文。比如，一个进程的安全上下文对一个文件的安全上下文的访问权限；或者，一个进程的安全上下文切换后得到另一个进程的安全上下文的权限。

安全策略的格式多种多样，本实施例对此不作限定。

在一个示例中，安全策略的格式为：allow source_type(源类型)target_type(目标类型)class(类别)permission(许可)。该安全策略的格式代表的含义为：允许source_type对target_type拥有class下的permission权限。

其中，source_type通常是主体的安全上下文的类型；target_type是客体的安全上下文的类型；class用于定义客体的安全上下文的类型拥有的所有权限，例如：定义一个class为file，该file的权限包括读、写、执行等；permission用于表示向source_type许可的权限，通常是class定义的所有权限的子集。

例如：安全策略为allow init system_file file execute，代表的含义为：init进程对system_file文件拥有file的执行权限。在该安全策略的基础上，结合安全上下文中的两个举例可知，安全上下文u：r：init：s0对安全上下文u：object_r：system_file：s0的toolbox文件拥有执行权限。

在另一个示例中，安全策略的格式为：deny source_type target_type classpermission。该安全策略的格式代表的含义为：删除source_type对target_type在class下的permission权限。

例如：安全策略为deny init system_file file execute，代表的含义为：删除init进程对system_file文件拥有的file下的执行权限。

在又一个示例中，安全策略的格式为：type_trans(转换)source_type(源类型)target_type(目标类型)class(类别)trans_type(转换类型)。该安全策略的格式代表的含义为：类型为source_type的进程根据class拥有的权限访问target_type后，转换为类型为trans_type的进程。

例如：安全策略为type_trans init zygote_exec file zygote，代表的含义为：type为init的进程执行type为zygote_exec的文件之后，进程的type变为了zygote。

当然，安全策略的格式还可以包括其他格式，此处不再一一列举。

系统模式：系统模式用于统一管理某一安全上下文对所有其他安全上下文的权限，该权限包括访问其他安全上下文的权限或者切换至任一其他安全上下文的权限。系统模式预设在操作系统中，主要包括三种分别为：disabled(关闭)模式、enforcing(强制)模式和permissive(允许)模式。

当操作系统启动disabled模式时，SEAndroid安全机制关闭。

当操作系统启动enforcing模式时，SEAndroid安全机制启动并阻止不被安全策略文件允许的访问。

当操作系统对某一安全上下文启动permissive模式时，该permissive模式用于指示该安全上下文在操作系统启动enforcing模式时，SEAndroid安全机制启动并不阻止不被安全策略文件允许的访问。规定某一安全上下文启动permissive模式的格式为：permissive type。例如：permissive init，则init进程可以违反安全策略，访问各种系统文件或转换为其它任意的进程。

内核空间(或称，核心空间)：虚拟内存中用于运行内核及驱动程序的区块。

用户空间(或称，使用者空间)：虚拟内存中用于运行应用程序的区块，该应用程序是操作系统提供的默认应用，和/或用户安装的第三方应用。

相关技术中，开发者需要基于安全策略文件的源代码来更新移动终端中的安全策略文件，由于只有发布该源代码的开发者才能获取到该源代码，因此，造成了该更新安全策略文件的方法的应用对象不够广泛，可能导致更新移动终端中的安全策略文件不够及时的问题。基于此问题，本发明实施例提供的安全策略更新方法，提供了如下技术方案：在移动终端获取到安全策略文件的补丁文件时，将加载到内核空间中的安全策略文件在用户空间展开，在该用户空间中根据该补丁文件更新该安全策略文件，得到更新后的安全策略文件；然后，再将更新后的安全策略文件从用户空间写回至内核空间。由于用户空间展开的安全策略文件为该安全策略文件的源代码的有效部分，且开发者主要是对源代码中的有效部分进行更新，这样，开发者只需要发布安全策略文件的补丁文件，不需要获取到安全策略文件的源代码，就可以实现对安全策略文件的更新，提高了更新安全策略文件的方法的通用性。其中，安全策略文件的源代码中的有效部分用于指示各个安全上下文的安全策略，以及，用于构成该安全策略的相关信息，比如：定义的class、type、属性等信息。

可选地，本发明实施例提供的方法，各步骤的执行主体为安装Android操作系统，且该Android操作系统的类型为SEAndroid的移动终端，该移动终端可以为手机、平板电脑、可穿戴式设备等，本发明实施例对此不作限定。移动终端中安装有策略更新应用，该策略更新应用用于更新移动终端中的安全策略文件，该策略更新应用在实际实施例中具有各种可能的应用名称，例如：手机管家、净化大师、一键ROOT等。以下实施例中以各步骤的执行主体为移动终端中的策略更新应用进行举例说明。

请参考图1，其示出了本发明一个实施例提供的安全策略更新方法的流程图。该方法可以包括以下几个步骤：

步骤101，获取安全策略文件的补丁文件。

补丁文件用于对移动终端当前的安全策略文件的漏洞进行修复，且补丁文件中包括至少一条待更新的第一安全策略，该补丁文件可以是由开发者编译并上传至服务器中的，也可以是策略更新应用生成的。

在补丁文件由开发者编译并上传至服务器的情况下，策略更新应用获取该服务器中的补丁文件，获取的方式包括但不限于以下几种：

在第一种方式中，服务器在接收到开发者上传的补丁文件时，向移动终端推送该补丁文件，策略更新应用接收该补丁文件。

在第二种方式中，策略更新应用每隔预定时长向服务器发送更新请求，服务器在接收到更新请求，且接收到开发者上传的补丁文件时，向移动终端推送该补丁文件，策略更新应用接收该补丁文件。

可选地，该补丁文件还可以由策略更新应用来预设或实时生成，比如，策略更新应用的安装包中携带有补丁文件，当策略更新应用被安装后，策略更新应用在本地目录中获取补丁文件。又比如，在补丁文件是策略更新应用实时生成的情况下，该策略更新应用获取补丁文件包括：接收权限设置指令；根据该权限设置指令生成第一安全策略；根据该第一安全策略生成补丁文件。

其中，权限设置指令包括策略更新应用中用于申请权限的进程的类型，以及该类型的进程所申请的权限。权限设置指令可以是用户触发生成的，也可以是策略更新文件在安装成功时自动生成的，本实施例对此不作限定。

例如：用户触发策略更新应用中的一键ROOT选项，策略更新应用生成权限设置指令，该权限设置指令包括用于申请ROOT权限的进程的类型init，以及，类型为init的进程所申请的权限permissive。

策略更新应用根据权限设置指令生成第一安全策略，包括：根据安全策略的格式，将权限设置指令包括的进程的类型以及权限组合成第一安全策略。

例如：权限设置指令包括的进程的类型为init，权限为permissive，根据安全策略的格式组成的第一安全策略为permissive init。

步骤102，将安全策略文件从内核空间读取到用户空间。

移动终端中的安全策略文件预先保存在文件系统中，在操作系统启动的过程中，init进程(操作系统中层级最高的父进程)将文件系统挂载到/sys/fs/selinux/下，SEAndroid内核驱动程序通过该文件系统与用户空间中的应用程序进行通信，此时，该文件系统中的安全策略文件被加载到内核空间。其中，SEAndroid内核驱动程序是内核空间中运行的驱动程序中的一种。本实施例不对该文件系统的类型作限定，在一个示例中，该文件系统为selinuxfs文件系统。

由于用户空间中运行的应用程序是无权对内核空间中的文件直接进行修改的，因此，策略更新应用无法在内核空间中直接更新安全策略文件。本实施例通过将内核空间中的安全策略文件读取到用户空间，由于策略更新应用有权对用户空间中的文件进行修改，因此，实现了策略更新应用对安全策略文件的更新。

策略更新应用将安全策略文件从内核空间读取到用户空间，包括以下几个步骤：

1、打开内核空间和用户空间之间的第一文件接口，该第一文件接口用于读取内核空间中的安全策略文件。第一文件接口的作用相当于内核空间与用户空间之间的通道，在该第一文件接口打开时，内核空间与用户空间之间的通道开启。本实施例不对第一文件接口作限定，在一个示例中，该第一文件接口为/sys/fs/selinux/policy。

2、通过第一文件接口将安全策略文件从内核空间映射至用户空间。

第一文件接口调用映射函数将安全策略文件从内核空间映射至用户空间，由于策略更新应用没有读取内核空间中的安全策略文件的权限，因此，映射函数的作用相当于将安全策略文件由不可读的状态变成可读的状态。本实施例不对该映射函数作限定，在一个示例中，该映射函数为mmap，该映射函数mmap会将安全策略文件映射至内存中，变成可读的状态。

3、在用户空间中，通过第一编程接口将安全策略文件从二进制形式展开为结构体形式，并关闭第一文件接口。

由于策略更新应用无法直接解析二进制形式的安全策略文件的具体含义，而可以解析结构体形式的安全策略文件的具体含义，因此，策略更新应用需要调用第一编程接口将安全策略文件由二进制形式解析为结构体形式，以保证策略更新应用可以根据补丁文件准确地更新安全策略文件。第一编程接口预先设置在操作系统中，本实施例不对该第一编程接口作限定，在一个示例中，该第一编程接口为libsepol库API(ApplicationProgramming Interface，应用程序编程接口)。

另外，策略更新应用将安全策略文件读取至用户空间以后，为了防止应用内存泄露，需要释放mmap的映射，并关闭第一文件接口。此时，相当于内核空间与用户空间之间的通道关闭。

下面介绍在用户空间展开的结构体形式的安全策略文件包括的文件内容，该文件内容是安全策略文件的源代码中的有效部分。

1、定义的user、role、type和class等元素。

对于user和role的定义比较固定，在SEAndroid中，user的定义为“u”；role的定义为“r”或者“object_r”，此部分在上文已经提及，在此不作赘述。对于type和class的定义则比较灵活，可由开发者自行定义。例如：定义的type为system_file，定义的class为file。

2、type与属性之间的从属关系。

不同的type可能具有相同的安全策略，为了避免对多个type重复定义相同的安全策略，SEAndroid中还提供了属性，具有相同属性的至少两个type对应的部分安全策略相同。换句话说，假如有10个type具有相同的安全策略，则可以将这10个type设置为具有同一种属性，再对该属性设置一条安全策略即可。通过设置type与属性之间的从属关系，使得策略更新应用在更新具有相同属性的至少两个type对应的安全策略时，只需要定义与该属性对应的安全策略即可，不需要逐个定义每个type对应的安全策略。这样，策略更新应用获取到的补丁文件中的第一安全策略的数量会减少，策略更新应用所需执行的更新操作的次数也会减少。

例如：type1和type2具有相同的属性1，在第一种情况中，开发者为type1和type2分别定义安全策略，则需要定义至少两条安全策略。在第二种情况中，开发者仅为属性1定义安全策略，则相较于第一种情况来说，开发者至少可以省略定义一条安全策略。显然地，随着type的数量的增多，省略定义的安全策略的数量也会增多。

需要说明的是，本实施例不对type与属性之间的从属关系的表示方式作限定，在一个示例中，type与属性之间的从属关系通过位图数组表示。

假设通过位图数组表示的type与属性之间的从属关系如下表一所示。在表一中，每一行代表一个type，每一列代表一种属性，标为1的位置代表该行的type属于该列的属性。例如：type1为系统应用，type2为第三方应用，属性1为应用。一个type可以具有多个属性，一个属性通常也对应多个type。

表一

	属性1	属性2	属性3	.......
					type1	1	1
type2	1		1
					type3	1
……

3、第二安全策略。

第二安全策略是指在策略更新应用对安全策略文件更新前，更新前的安全策略文件所包括的安全策略。

本实施例不对安全策略文件存储第二安全策略的方式作限定。

在一个示例中，第二安全策略通过哈希表存储在安全策略文件中。哈希表是一种键值key-value存储结构。

哈希表用于根据key(键)访问内存中的数据结构，即访问对应的value(值)。在存储一条安全策略时，哈希表中的键至少包括class、source_type和target_type；哈希表中的值为权限集合或者切换后的安全上下文。当哈希表中的值为权限集合时，说明对应的键值对代表的含义为一个安全上下文对另一安全上下文的访问权限；当哈希表中的值为切换后的安全上下文时，说明对应的键值对代表的含义为一个安全上下文切换到另一安全上下文。

假设通过哈希表存储的第二安全策略如下表二所示，第一行的键值对代表的含义为类型为init的进程对system_file拥有file下的execute(执行)，write(写)和read(读)的权限；第二行的键值对代表的含义为类型为init的进程执行apache_exec之后，进程的type变为了apache。

表二

需要说明的是，在实际实现时，哈希表中的值可以通过位图数组表示，并将source_type对target_type所具有的权限在该位图中对应的权限位置进行标识。本实施例不对该位图数组的位数作限定，在一个示例中，该位图数组的位数为32位。其中，当class定义的权限的数量大于位图数组的位数时，操作系统通过多个位图数组存储class定义的权限，当class定义的权限的数量小于位图数组的位数时，操作系统对该位图数组的冗余位作无效处理。

假设位图数组的位数为32位，表示source_type对target_type所拥有的权限的位图如下表三所示。其中，“第一位”至“第三十一位”代表class定义的31种不同的权限，标识1代表source_type对target_type具有对应位指示的权限，标识0代表source_type对target_type不具有对应位指示的权限。由于第三十二位为冗余位，操作系统对该位作了无效处理，因此，该位图数组中不包括第三十二位。

表三

第一位	第二位	第三位	第四位	……	第三十一位
						1	0	0	1	……	1

步骤103，根据补丁文件在用户空间更新安全策略文件，得到更新后的安全策略文件。

由于策略更新应用具有在用户空间修改安全策略文件的权限，因此，策略更新应用可以根据补丁文件更新该安全策略文件。

当补丁文件是开发者根据结构体形式编译并上传至服务器中时，策略更新应用获取到的补丁文件中的第一安全策略的形式与用户空间中的第一安全策略的形式相符，该策略更新应用直接根据第一安全策略在用户空间更新安全策略文件。在这种情况下，开发者需要了解结构体形式，才能保证策略更新应用可以成功地根据第一安全策略在用户空间更新安全策略文件。

为了降低开发者编译补丁文件的难度，本实施例中，可选通过预设的解析器预先将开发者编译的补丁文件解析为结构体形式，策略更新应用仍旧可以获取到形式与用户空间中的安全策略文件的形式相同的补丁文件。在这种情况下，开发者可以使用任一形式的编程语言编译第一安全策略，比如：c++语言、JAVA语言等，在保证了策略更新应用能够成功根据第一安全策略更新安全策略文件的前提下，降低了开发者编译补丁文件的难度。

策略更新应用根据补丁文件在用户空间更新安全策略文件，得到更新后的安全策略文件，包括：从补丁文件中获取第一安全策略；根据第一安全策略，在用户空间中对安全策略文件进行更新，得到更新后的安全策略文件。

本实施例通过根据第一安全策略，在用户空间中对安全策略文件进行更新，使得策略更新应用对安全策略文件的更新粒度为一条条的安全策略，而不是整个安全策略文件，减少了需要编译的安全策略的数量。

策略更新应用根据第一安全策略，在用户空间中对安全策略文件进行更新，得到更新后的安全策略文件，包括如下步骤，如图2所示：

步骤1031，获取第一安全策略对应的更新操作、策略对象和策略内容。

更新操作用于指示策略更新应用对安全策略文件执行的操作，该更新操作包括添加安全策略、修改安全策略和删除安全策略中的至少一种。其中，不同的更新操作通过不同的语法表示，比如：添加安全策略的语法为allow语法；修改安全策略的语法为type_trans语法；删除安全策略的语法为deny语法，本实施例对此不作限定。

策略对象是第一安全策略所规定的source_type、target_type和class。在一个示例中，当第二安全策略通过哈希表存储在安全策略文件中时，该策略对象即为哈希表中的键，例如：表二第一行中的source_type、target_type和class。

策略内容是class下的permission权限或者source_type切换后的type。在一个示例中，当第二安全策略通过哈希表存储在安全策略文件中时，该策略内容即为哈希表中的值。例如：表二第一行中的execute，write，read。

第一安全策略是根据预设格式编译的，策略更新应用通过从该预设格式中读取更新操作、策略对象和策略内容来获取第一安全策略对应的更新操作、策略对象和策略内容。

例如：第一安全策略为allow init system_file file execute，则更新操作为allow语法指示的添加操作，策略对象为init、system_file和file，策略内容为execute。

步骤1032，当更新操作是添加安全策略时，在安全策略文件中添加第一安全策略的策略对象和策略内容。

可选地，为了防止安全策略文件包括策略对象相同的两条相同的安全策略，使得移动终端无法确定出该策略对象对应的策略内容，在本步骤之前，策略更新应用还会检测安全策略文件是否包括与第一安全策略文件具有相同的策略对象的第二安全策略，在安全策略文件不包括与第一安全策略文件具有相同的策略对象的第二安全策略时，策略更新应用在安全策略文件中添加第一安全策略的策略对象和策略内容；在安全策略文件包括与第一安全策略文件具有相同的策略对象的第二安全策略时，策略更新应用执行修改安全策略的步骤，即步骤1033。

例如：第一安全策略为allow zygote init process sigchld，且移动终端中的安全策略文件如表二所示，表二不包括该第一安全策略中的策略对象，则策略更新应用将该第一安全策略添加入表二所示的安全策略文件中。

需要说明的是，当第一安全策略的策略对象中的source_type为属性时，策略更新应用在哈希表中添加了该第一安全策略后，还需要扩展移动终端中预存的type与属性之间的从属关系(也即上述的位图数组)，以供移动终端在运行具有该属性的进程时，可以根据该从属关系和该安全策略文件确定该进程拥有的权限。

若更新安全策略文件的操作包括删除安全策略，此时，安全策略文件不存在待更新的安全策略，无法执行删除操作，因此，流程结束。

步骤1033，当更新操作是修改安全策略时，在安全策略文件中查找与第一安全策略具有相同的策略对象的第二安全策略；根据第一安全策略的策略内容修改第二安全策略的策略内容。

可选地，当策略更新应用在安全策略文件中未查找到与第一安全策略具有相同的策略对象的第二安全策略时，策略更新应用安全策略文件中添加该第一安全策略。

例如：第一安全策略为init apache_exec process init，且移动终端中的安全策略文件如表二所示，表二包括与该第一安全策略中的策略对象相同的第二安全策略，则策略更新应用将该第二安全策略的策略内容apache修改为init。

步骤1034，当更新操作是删除安全策略时，在安全策略文件中查找与第一安全策略具有相同的策略对象的第二安全策略；在第二安全策略的策略内容中删除第一安全策略的策略内容。

可选地，当策略更新应用在安全策略文件中未查找到与第一安全策略具有相同的策略对象的第二安全策略时，本次更新安全策略的流程结束。

例如：第一安全策略为allow init system_file file{execute read}，且移动终端中的安全策略文件如表二所示，表二包括与该第一安全策略中的策略对象相同的第二安全策略，则策略更新应用将该第一安全策略的策略内容execute和read从第二安全策略的策略内容中删除。

需要说明的是，每次更新安全策略文件的流程中，上述更新操作可能不会全部执行，只执行一种或者两种更新操作，本实施例不对执行的更新操作的数量及执行的顺序作限定。

步骤104，将更新后的安全策略文件从用户空间写回内核空间。

策略更新应用将用户空间中的更新后的安全策略文件写回内核空间，以便后续移动终端在内核空间创建进程时，可以根据该内核空间中的更新后的安全策略文件确定出该进程所拥有的权限，提高移动终端运行的安全性。

策略更新应用将用户空间中的更新后的安全策略文件写回内核空间，包括以下几个步骤：

1、打开内核空间和用户空间之间的第二文件接口。

第二文件接口用于将用户空间中的安全策略文件写回内核空间。第二文件接口的作用相当于内核空间与用户空间之间的另一条通道，在该第二文件接口打开时，内核空间与用户空间之间的另一条通道开启。本实施例不对第二文件接口作限定，在一个示例中，该第二文件接口为/sys/fs/selinux/load。

2、在用户空间中，通过第二编程接口将更新后的安全策略文件从结构体形式编译成二进制形式。

第二编程接口是用户空间中预设的接口，本实施例对第二编程接口不作限定。

3、通过第二文件接口将二进制形式的更新后的安全策略文件写回内核空间，并关闭所述第二文件接口。

综上所述，本实施例提供的方法，通过将安全策略文件从内核空间读取到用户空间，使用补丁文件对用户空间中的安全策略文件进行更新，使得开发者无需获取到安全策略文件的源代码，仅需要编译待更新的安全策略并生成补丁文件，即可使用补丁文件在用户空间中实现对移动终端中的安全策略文件的源代码进行更新，这样不具有源代码获取能力的开发者也可以对移动终端中的安全策略文件进行更新，既提高了安全策略更新方法的通用性，也提高了更新安全策略文件的及时性。

另外，通过策略更新应用根据第一安全策略，在用户空间中对安全策略文件进行更新，使得安全策略文件的更新粒度由整个文件缩小为每条安全策略，这样，既减少了开发者需要编译的第一安全策略的数量，相较于服务器向移动终端发送整个安全策略文件来说，还节省了服务器的传输资源。

另外，由于系统重启时，需要将文件系统中的未更新的安全策略文件重新加载到内核空间，因此，通过将用户空间中的更新后的安全策略文件写回内核空间，使得本次更新后的安全策略文件将会在系统重启时被文件系统中的未更新的安全策略文件覆盖，即，本次更新后的安全策略文件仅在本次系统运行期间适用，这样，提高了更新后的安全策略文件适用的时长的灵活性。

基于图1所示的实施例，请参考图3，其示出了本发明另一个实施例提供的安全策略更新方法的流程图。由图3可知，在步骤103之后，该方法还可以包括以下步骤：

步骤105，使用更新后的安全策略文件替换位于文件系统中的安全策略文件，文件系统中的安全策略文件用于在操作系统启动时被加载至内核空间。

由于系统重启时，需要将文件系统中的安全策略文件加载到内核空间，以供移动终端在创建进程时，可以根据该内核空间中的安全策略文件确定该进程拥有的权限，因此，当需要长久使用更新后的安全策略文件时，可以利用更新后的安全策略文件替换文件系统中的安全策略文件，这样，系统每次重启时，都会从文件系统中加载更新后的安全策略文件，保证了更新后的安全策略文件的长久使用。

可选地，本步骤可以在步骤104之后执行；也可以在步骤104之前执行；还可以与步骤104同时执行；还可以不执行步骤104，直接执行步骤105，本实施例对此不作限定。

可选地，基于图1和图3所示的实施例，请参考图4，其示出了本发明另一个实施例提供的安全策略更新方法的流程图。在步骤101之前，该安全策略更新方法还可以包括以下步骤：

步骤401，接收安全上下文对最高权限的获取请求。

每个安全上下文对应一个进程或文件，最高权限是一个安全上下文具有对所有其他安全上下文的访问权限，和/或，一个安全上下文具有切换到任一其他安全上下文的权限。例如：root权限。

可选地，获取请求包括策略更新应用生成的补丁文件，其中，策略更新应用生成的补丁文件的过程详见步骤101，此处不作赘述。该获取请求可以是用户触发生成的，也可以是策略更新应用在安装完成时自动生成的，本实施例对此不作限定。

步骤402，根据获取请求设置安全上下文的自由模式为开启状态，开启状态的自由模式用于指示对安全上下文不启用安全策略文件中的安全策略限制。

其中，自由模式即为上文中提及的permissive模式。根据permissive模式的定义可知，开启了permissive模式的安全上下文允许在运行过程中违反安全策略，因此，通过启动安全上下文的permissive模式，即可使得该安全上下文获取到最高权限。

对于不同的系统，permissive模式可能生效，也可能不生效。当系统的permissive模式生效时，安全上下文才能通过开启状态的permissive模式获取到最高权限。

可选地，当系统的permissive模式不生效时，为了响应该获取请求，策略更新应用需要创建一个属性，该属性具有对所有安全上下文的所有权限；在安全策略文件中添加第一安全策略，该第一安全策略用于规定该属性具有对所有安全上下文的所有权限；将发送获取请求的安全上下文的type添加到该属性中，则该安全上下文具有对所有安全上下文的所有权限。在这种情况下，策略更新应用根据补丁文件更新安全策略文件的过程，与图1所示的实施例步骤102-103中的策略更新应用根据补丁文件添加安全策略文件的过程相同，此处不多作赘述。

例如：移动终端中保存的安全策略文件如表二所示，当操作系统的permissive模式不生效，且接收到init类型的进程发送的最高权限的获取请求时，更新后的安全策略文件如下表四所示。

表四

根据上述步骤1032可知，由于操作系统创建了新的属性permissive，此时，需要对type和属性之间的从属关系进行扩充。

假设在操作系统创建属性permissive之前type和属性之间的从属关系如表一所示，则操作系统对type和属性之间的从属关系进行扩充之后得到的从属关系如下表五所示。根据表五可知，permissive属性包括发送最高权限的获取请求的进程对应的类型init。

表五

可选地，在本步骤之前，策略更新应用还可以输出提示信息，该提示信息用于提示用户是否允许发送获取请求的安全上下文获取最高权限，在用户允许该安全上下文获取最高权限时，策略更新应用再执行本步骤。

综上所述，本实施例提供的方法，通过在接收到安全上下文发送的最高权限的获取请求时，在安全策略文件中更新该安全上下文的自由模式，实现了安全上下文获取到操作系统的最高权限的功能。

下面对本发明应用的具体场景进行举例说明。

在一个示例中，策略更新应用为手机管家，移动终端为手机。手机管家获取服务器中的补丁文件，将手机中的安全策略文件从内核空间读取到用户空间，并在用户空间展开为结构体形式，得到该安全策略文件的源代码的有效部分；手机管家根据该补丁文件对该安全策略文件进行更新，得到更新后的安全策略文件；然后，手机管家将该更新后的安全策略文件从用户空间写回内核空间，或者，将该更新后的安全策略文件从用户空间写回文件系统。

在另一示例中，策略更新应用为KingRoot，移动终端为手机。用户触发KingRoot中的一键Root功能，移动终端在接收到触发操作时，创建一个类型为init的进程，该进程对应的安全上下文向操作系统发送最高权限的获取请求以使得KingRoot获取到该最高权限，操作系统开启该安全上下文的permissive模式，此时，KingRoot获取到最高权限。

下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。

请参考图5，其示出了本发明一个实施例提供的安全策略更新装置的框图。该装置具有执行上述方法示例的功能，功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置可以包括：获取模块510、读取模块520、更新模块530和写回模块540。

获取模块510，用于执行上述步骤101。

读取模块520，用于执行上述步骤102。

更新模块530，用于执行上述步骤103。

写回模块540，用于执行上述步骤104。

可选地，更新模块530，包括：获取单元和更新单元。

获取单元，用于从补丁文件中获取待更新的第一安全策略；

更新单元，用于根据第一安全策略，在用户空间中对安全策略文件进行更新，得到更新后的安全策略文件。

可选地，更新单元，还用于执行上述步骤1031-1034。

可选地，获取模块，具体用于：

获取服务器中的补丁文件，服务器中的补丁文件由开发者编译并上传。

可选地，该装置还包括：接收模块和设置模块。

接收模块，用于执行上述步骤401。

设置模块，用于执行上述步骤402。

可选地，读取模块，具体用于执行上述步骤102中的步骤1-3。

可选地，写回模块，具体用于执行上述步骤104中的步骤1-3。

可选地，该装置还包括：替换模块。

替换模块，用于执行上述步骤105。

相关细节可参考图1、图3、图4所示的方法实施例。

需要说明的是：上述实施例提供的装置在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

请参考图6，其示出了本发明一个实施例提供的移动终端的结构示意图。该移动终端600用于实施上述实施例中提供的安全策略更新方法。具体来讲：

移动终端600可以包括RF(Radio Frequency，射频)电路610、包括有一个或一个以上计算机可读存储介质的存储器620、输入单元630、显示单元640、传感器650、音频电路660、WiFi(wireless fidelity，无线保真)模块670、包括有一个或者一个以上处理核心的处理器680、以及电源690等部件。本领域技术人员可以理解，图6中示出的移动终端结构并不构成对移动终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

RF电路610可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器680处理；另外，将涉及上行的数据发送给基站。通常，RF电路610包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(SIM)卡、收发信机、耦合器、LNA(Low Noise Amplifier，低噪声放大器)、双工器等。此外，RF电路610还可以通过无线通信与网络和其它设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于GSM(Global System of Mobile communication，全球移动通讯系统)、GPRS(General Packet Radio Service，通用分组无线服务)、CDMA(CodeDivision Multiple Access，码分多址)、WCDMA(Wideband Code Division MultipleAccess,宽带码分多址)、LTE(Long Term Evolution,长期演进)、电子邮件、SMS(ShortMessaging Service，短消息服务)等。

存储器620可用于存储软件程序以及模块，处理器680通过运行存储在存储器620的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器620可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(例如声音播放功能、图像播放功能等)等；存储数据区可存储根据移动终端600的使用所创建的数据(例如音频数据、电话本等)等。此外，存储器620可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其它易失性固态存储器件。相应地，存储器620还可以包括存储器控制器，以提供处理器680和输入单元630对存储器620的访问。

输入单元630可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，输入单元630可包括图像输入设备631以及其它输入设备632。图像输入设备631可以是摄像头，也可以是光电扫描设备。除了图像输入设备631，输入单元630还可以包括其它输入设备632。具体地，其它输入设备632可以包括但不限于物理键盘、功能键(例如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元640可用于显示由用户输入的信息或提供给用户的信息以及移动终端600的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元640可包括显示面板641，可选地，可以采用LCD(Liquid Crystal Display，液晶显示器)、OLED(Organic Light-Emitting Diode，有机发光二极管)等形式来配置显示面板641。

移动终端600还可包括至少一种传感器650，例如光传感器、运动传感器以及其它传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板641的亮度，接近传感器可在移动终端600移动到耳边时，关闭显示面板641和/或背光。作为运动传感器的一种，重力加速度传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(例如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(例如计步器、敲击)等；至于移动终端600还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其它传感器，在此不再赘述。

音频电路660、扬声器661，传声器662可提供用户与移动终端600之间的音频接口。音频电路660可将接收到的音频数据转换后的电信号，传输到扬声器661，由扬声器661转换为声音信号输出；另一方面，传声器662将收集的声音信号转换为电信号，由音频电路660接收后转换为音频数据，再将音频数据输出处理器680处理后，经RF电路610以发送给例如另一移动终端，或者将音频数据输出至存储器620以便进一步处理。音频电路660还可能包括耳塞插孔，以提供外设耳机与移动终端600的通信。

WiFi属于短距离无线传输技术，移动终端600通过WiFi模块670可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图6示出了WiFi模块670，但是可以理解的是，其并不属于移动终端600的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器680是移动终端600的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器620内的软件程序和/或模块，以及调用存储在存储器620内的数据，执行移动终端600的各种功能和处理数据，从而对手机进行整体监控。可选地，处理器680可包括一个或多个处理核心；优选的，处理器680可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器680中。

移动终端600还包括给各个部件供电的电源690(例如电池)，优选的，电源可以通过电源管理系统与处理器680逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源690还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管未示出，移动终端600还可以包括蓝牙模块等，在此不再赘述。

具体在本实施例中，移动终端600还包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行。上述一个或者一个以上程序包含用于执行上述方法的指令。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器620，上述指令可由移动终端600的处理器680执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (14)

1.一种安全策略更新方法，其特征在于，所述方法包括：

获取安全策略文件的补丁文件，所述安全策略文件保存在文件系统中，在操作系统启动的过程中，所述文件系统中的安全策略文件被加载到内核空间，所述补丁文件为服务器中下载的文件或者策略更新应用生成的文件；

打开所述内核空间和用户空间之间的第一文件接口；其中，所述内核空间是指虚拟内存中用于运行内核及驱动程序的区块，所述用户空间是指所述虚拟内存中用于运行应用程序的区块；

通过所述第一文件接口将所述安全策略文件从所述内核空间映射至所述用户空间；

在所述用户空间中，通过第一编程接口将所述安全策略文件从二进制形式展开为结构体形式，并关闭所述第一文件接口；

根据所述补丁文件在所述用户空间更新所述安全策略文件，得到更新后的安全策略文件；

将所述更新后的安全策略文件从所述用户空间写回所述内核空间。

2.根据权利要求1所述的方法，其特征在于，所述根据所述补丁文件在所述用户空间更新所述安全策略文件，得到更新后的安全策略文件，包括：

从所述补丁文件中获取待更新的第一安全策略；

根据所述第一安全策略，在所述用户空间中对所述安全策略文件进行更新，得到所述更新后的安全策略文件。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第一安全策略，在所述用户空间中对所述安全策略文件进行更新，包括：

获取所述第一安全策略对应的更新操作、策略对象和策略内容，所述更新操作包括添加安全策略、修改安全策略和删除安全策略中的至少一种；

当所述更新操作是所述添加安全策略时，在所述安全策略文件中添加所述第一安全策略的所述策略对象和所述策略内容；

当所述更新操作是所述修改安全策略时，在所述安全策略文件中查找与所述第一安全策略具有相同的所述策略对象的第二安全策略；根据所述第一安全策略的所述策略内容修改所述第二安全策略的策略内容；

当所述更新操作是所述删除安全策略时，在所述安全策略文件中查找与所述第一安全策略具有相同的所述策略对象的第二安全策略；在所述第二安全策略的策略内容中删除所述第一安全策略的所述策略内容；

其中，所述第二安全策略存储于所述安全策略文件中。

4.根据权利要求1至3任一所述的方法，其特征在于，所述方法还包括：

接收安全上下文对最高权限的获取请求，所述安全上下文对应一个进程或文件，所述最高权限是所述安全上下文具有对所有其他安全上下文的访问权限，和/或，所述安全上下文具有切换到任一其他安全上下文的权限；

根据所述获取请求设置所述安全上下文的自由模式为开启状态，所述开启状态的自由模式用于指示对所述安全上下文不启用所述安全策略文件中的安全策略限制。

5.根据权利要求1至3任一所述的方法，其特征在于，所述将所述更新后的安全策略文件从所述用户空间写回所述内核空间，包括：

打开所述内核空间和所述用户空间之间的第二文件接口；

在所述用户空间中，通过第二编程接口将所述更新后的安全策略文件从结构体形式编译成二进制形式；

通过所述第二文件接口将二进制形式的所述更新后的安全策略文件写回所述内核空间，并关闭所述第二文件接口。

6.根据权利要求1至3任一所述的方法，其特征在于，所述方法还包括：

使用所述更新后的安全策略文件替换位于文件系统中的安全策略文件，所述文件系统中的安全策略文件用于在操作系统启动时被加载至所述内核空间。

7.一种安全策略更新装置，其特征在于，所述装置包括：

获取模块，用于获取安全策略文件的补丁文件，所述安全策略文件保存在文件系统中，在操作系统启动的过程中，所述文件系统中的安全策略文件被加载到内核空间，所述补丁文件为服务器中下载的文件或者策略更新应用生成的文件；

读取模块，用于将所述安全策略文件从内核空间读取到用户空间；其中，所述内核空间是指虚拟内存中用于运行内核以及驱动程序的区块，所述用户空间是指所述虚拟内存中用于运行应用程序的区块；

更新模块，用于根据所述补丁文件在所述用户空间更新所述安全策略文件，得到更新后的安全策略文件；

写回模块，用于将所述更新后的安全策略文件从所述用户空间写回所述内核空间；

所述读取模块，用于：

打开所述内核空间和所述用户空间之间的第一文件接口；

通过所述第一文件接口将所述安全策略文件从所述内核空间映射至所述用户空间；

在所述用户空间中，通过第一编程接口将所述安全策略文件从二进制形式展开为结构体形式，并关闭所述第一文件接口。

8.根据权利要求7所述的装置，其特征在于，所述更新模块，包括：

获取单元，用于从所述补丁文件中获取待更新的第一安全策略；

更新单元，用于根据所述第一安全策略，在所述用户空间中对所述安全策略文件进行更新，得到所述更新后的安全策略文件。

9.根据权利要求8所述的装置，其特征在于，所述更新单元，用于：

获取所述第一安全策略对应的更新操作、策略对象和策略内容，所述更新操作包括添加安全策略、修改安全策略和删除安全策略中的至少一种；

当所述更新操作是所述添加安全策略时，在所述安全策略文件中添加所述第一安全策略的所述策略对象和所述策略内容；

当所述更新操作是所述修改安全策略时，在所述安全策略文件中查找与所述第一安全策略具有相同的所述策略对象的第二安全策略；根据所述第一安全策略的所述策略内容修改所述第二安全策略的策略内容；

当所述更新操作是所述删除安全策略时，在所述安全策略文件中查找与所述第一安全策略具有相同的所述策略对象的第二安全策略；在所述第二安全策略的策略内容中删除所述第一安全策略的所述策略内容；

其中，所述第二安全策略存储于所述安全策略文件中。

10.根据权利要求7至9任一所述的装置，其特征在于，所述装置还包括：

接收模块，用于接收安全上下文对最高权限的获取请求，所述安全上下文对应一个进程或文件，所述最高权限是所述安全上下文具有对所有其他安全上下文的访问权限，和/或，所述安全上下文具有切换到任一其他安全上下文的权限；

设置模块，用于根据所述获取请求设置所述安全上下文的自由模式为开启状态，所述开启状态的自由模式用于指示对所述安全上下文不启用所述安全策略文件中的安全策略限制。

11.根据权利要求7至9任一所述的装置，其特征在于，所述写回模块，用于：

打开所述内核空间和所述用户空间之间的第二文件接口；

在所述用户空间中，通过第二编程接口将所述更新后的安全策略文件从结构体形式编译成二进制形式；

通过所述第二文件接口将二进制形式的所述更新后的安全策略文件写回所述内核空间，并关闭所述第二文件接口。

12.根据权利要求7至9任一所述的装置，其特征在于，所述装置还包括：

替换模块，用于使用所述更新后的安全策略文件替换位于文件系统中的安全策略文件，所述文件系统中的安全策略文件用于在操作系统启动时被加载至所述内核空间。

13.一种计算机设备，其特征在于，所述计算机设备包括存储器，以及一个或者一个以上的程序，所述一个或者一个以上的程序存储于所述存储器中，且经配置以由所述一个或者一个以上处理器执行以实现权利要求1-6任一项所述的安全策略更新方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括存储器，所述存储器存储有指令，所述指令由计算机设备的处理器执行以实现权利要求1-6任一项所述的安全策略更新方法。

Images