2018, Vol. 27
2. 中国科学院 软件研究所 可信计算与信息保障实验室, 北京 100190
2. Trusted Computing and Information Assurance Laboratory, Institute of Software, Chinese Academy of Sciences, Beijing 100190, China
Android操作系统是一个基于Linux内核的开放源代码移动操作系统, 它由Google成立的开放手持设备联盟 (Open Handset Alliance, OHA)持续领导与开发. Android现已成为全球第一大操作系统.
最初的Android依赖于其基于Linux的自主访问控制(Discretionary Access Control, DAC)机制来提供安全边界. 自主访问控制的核心观点是基于用户ID和组ID的概念, 用户之间保持了相对的隔离性, 文件和程序都有自己的所有者, 也即用户, 用户只有在获得了相应的授权, 才能对其它用户拥有的资源文件或者进程进行相关的操作和通信. 同样的组ID是将具有相关属性的用户组合在一起, 同时规定了相应组用户具有操作对应资源的权限. 但是自主访问控制机制存在显著的缺点, 比如有缺陷或恶意的应用会泄露敏感数据、无法限制以root权限运行的任何系统守护进程或setuid程序等.
为了降低恶意程序对系统带来的损害, 2012年美国国家安全局(National Security Agency, NSA)推出系统安全强化套件SEAndroid[1], 它是将原来Linux平台上的安全子系统SELinux[2]移植到Android平台上. SEAndroid安全机制从Android 4.3版本开始正式引入, 不过此时SEAndroid仅是运行在Permissive模式之下, 也就是说该机制并没有产生实质功能, 只是对相关操作进行记录. Android 4.4版本打开了Enforcing模式, 但是仅对几个关键的域(installed, netd, vold, zygote)进行保护. 从Android 5.0版本开始, 所有的进程都运行在Enforcing模式下, SEAndroid 正式开始对系统安全起到了保护的作用[3].
SEAndroid安全策略直接决定系统安全状态, 其配置不当将带来严重安全问题, 比如应用程序若被错误地过度授予了不必要的访问权限, 将导致权限提升(CVE-2015-4640, CVE-2015-4641)[4,5]. 因此分析、检测SEAndroid安全策略中的安全漏洞是十分必要的.
目前有大量的SELinux访问控制策略的分析研究[6–11], 但这些研究所采用的方法没有将SEAndroid的特定方面考虑在内, 没有涉及SEAndroid的特定类型及策略结构, 因此不能直接使用这些方法对SEAndroid安全策略进行分析. 而目前SEAndroid安全策略的分析研究还比较少[12,13], 且现有的关于SEAndroid安全策略漏洞检测方法需要大量的手工操作, 要求用户有额外知识储备(如域、功能测试), 这无疑加重了用户的负担.
有鉴于此, 在本论文中, 我们结合自主访问控制机制提出一种基于能力依赖图的SEAndroid安全策略分析方法. 首先, 我们对SEAndroid的实现方法进行分析, 同时与SELinux进行比较, 构造系统信息和安全策略的抽取工具, 并对抽取的信息进行形式化的描述, 以建立准确而精简的安全策略配置模型. 其次, 以安全策略配置模型为输入, 设计和实现自动化的分析推理引擎, 生成能力依赖图. 最后, 从能力依赖图中提取攻击路径. 本文主要贡献有以下几点:
(1) 我们提出了基于能力依赖图的SEAndroid安全策略分析方法. 能力依赖图不仅描述了每个动作需要的前提条件和执行该动作产生的新的能力, 还描述了攻击者攻陷系统的所有可能方法.
(2) 基于我们的方法实现了原型系统. 原型系统由三部分构成: 系统事实收集器、能力依赖图图生成器、攻击路径分析器.
(3) 我们使用原型系统对多个版本Android系统的SEAndroid安全策略进行了评估与分析. 我们一共发现了8种攻击模式, 其中远程攻击模式2种, 本地攻击模式6种. 通过对比分析, 我们发现随着Android版本的提升, SEAndroid安全策略也进行了更新, 新的SEAndroid对系统提供了更强的约束和保护, 并且其中一种远程攻击模式已经在实际系统中得到了验证.
2 SEAndroidSEAndroid访问控制包括三种访问控制模型: 类型强制(Type Enforcement, TE)[14]、角色访问控制(Role-Based Access Control, RBAC)[15]、多层安全(Multi-Level Security, MLS)[16]. 在SEAndroid中, 每一个主体和客体都有一个安全上下文, 格式描述如下: user: role: type: security_level. 其中, user代表SEAndroid的用户, role是针对RBAC的, type针对TE, security_level针对MLS. 由于在SEAndroid中, 系统只定义了一个用户u和两个RBAC角色r和object_r, 因此TE是SEAndroid中最重要的访问控制模型, 本文也将SEAndroid中的TE模型部分作为我们的主要研究对象.
在TE中, 每一个主体(进程)和客体(如文件、TCP套接字)都有一个类型(type), 主体的类型也被成为域(domain). 具有共性的类型将被归在一起构成一个称为属性(attribute)的集合, 比如appdomain属性就是一些应用程序相关域的集合. 客体根据性质可以划分为不同的类别(class), 常见类别包括文件、目录、套接字等. 系统为每个类别定义了一组权限集合(permission set).
TE使用allow规则来控制主体对客体的访问, 使用type_transition规则来管理域转换和为新产生的客体指派类型. allow规则格式为: allow domain type:class {permission sets}. type_transition规则格式为: type_transition source_type target_type:class default_type.
Android系统启动时, 所有的策略配置文件被打包编译成一个二进制文件sepolicy, 系统将sepolicy加载进内核空间的Linux安全模块(Linux Security Module, LSM). LSM包含访问向量缓存(Access Vector Cache)和安全服务器(Security Server). 当一个进程主体以某种权限访问客体时, SEAndroid根据进程的域和客体的类型, 首先在AVC中查找是否存在该访问向量, 若存在则允许访问, 否则会在安全服务器中继续查找. 若安全服务器中存在该访问向量, 则允许访问并将访问向量写入AVC, 否则将禁止访问.
3 系统概述Android系统访问控制机制是提供用户权限隔离的主要安全机制, 而大多数攻击的前提是权限提升攻击, 因此我们主要关注权限提升攻击. 在整个权限提升攻击过程中, 每一个攻击步骤攻击者都能获取额外的能力, 并为下一步攻击做准备. 我们的目标是分析Android的访问控制机制, 实现一个推理系统, 发现当前访问控制配置中潜在的权限提升攻击. 系统包含三部分: 系统事实收集器、能力依赖图生成器、攻击路径分析器, 如图1所示. 系统事实收集器收集系统状态信息和SEAndroid安全策略信息, 并将这些信息声明为逻辑事实. 图生成器以收集器收集的系统事实、访问控制机制、推导规则的逻辑声明为输入, 给定攻击者的初始能力, 输出能力依赖图. 我们选定Prolog作为图生成器的逻辑分析引擎. Prolog是一种基于一阶谓词的逻辑性语言, 广泛应用于人工智能领域, 通常用来建造专家系统、智能知识库等. 由于SEAndroid策略定义了系统中主客体可允许行为的通用规则库, 主体行为在查询规则库并得到许可后方可执行, 而这都可用一阶谓词描述. 因此, Prolog的描述性语法很适合声明访问控制策略相关信息并查询特定权限是否可以满足. 以权限提升作为目标, 路径分析器遍历能力依赖图得到攻击路径和攻击模式.
|
图 1 系统框架图 |
4 系统设计与实现
在本部分, 我们将分别对系统的事实收集器、图生成器、路径分析器的具体设计实现进行详细介绍.
4.1 事实收集器事实收集器收集系统状态信息和SEAndroid安全策略配置信息, 并将其声明为Prolog事实.
一般与权限提升攻击相关的系统状态信息包括用户信息、文件信息、网络状态、进程信息和进程打开文件等. 需特别指出的是在Android系统中UID的含义不同于Linux, UID在Linux中用来唯一确定某个用户的身份, 而早期Android是单用户系统, 不需要支持多用户登陆. Android为每一个应用程序分配一个UID, 用UID对应用程序进行管理. Android中的UID分为系统UID和应用程序UID两部分, 系统UID包括root、WIFI、shell等, 可从AOSP提供的源码文件android_filesystem_config.h中获取. 应用程序UID包括calendar、email等, 可以从Android系统的packages.list中获取.
SEAndroid安全策略配置信息包括安全上下文和安全策略. 在SEAndroid安全机制中, 主体一般就是进程, 而客体一般就是文件. 故我们主要收集文件和进程的安全上下文. SEAndroid的安全策略主要存贮在以te为后缀的文件中, 而所有te文件最终会被系统打包成一个二进制文件——sepolicy. 我们借助SETools将sepolicy解析成文本文件. 在所有安全策略中, 我们主要关注规则名称为allow的访问向量和type_transition类型规则.
我们将上述收集到的信息编码为Prolog事实, 格式如表1所示. 其中, Owner, Group, Setuid, Setgid, Sticky, Uid, Pid, Port和Gid是数字. Type∈{dir, regular, …}. Protocol∈{tcp, udp}. Uper, Gper, Oper是用0、1代表read、write、execute权限的三元组. Gids, OpList是编码为Prolog表格式的集合. Path, Se_user, Se_role, Se_type, Username, Program, Domain, Filename, Class, Old_dom, New_dom, Attribute是字符串.
|
表 1 系统事实声明格式 |
4.2 图生成器
能力依赖图生成器以系统事实、访问控制机制和推导规则为输入, 生成能力依赖图.
4.2.1 能力依赖图能力依赖图描述了每个动作执行所需的前提条件和执行后生成的新的能力, 该图形象刻画了在Android访问控制机制限制下, 具有初始能力的攻击者可以获得的所有能力. 我们的SEAndroid安全策略分析就是基于能力依赖图的.
定义1. 能力依赖图(Capability Dependency Graph): 一个能力依赖图是一个有向图 G=(Ca∪Co, A, E), 其中, Ca是能力节点集合, Co是条件节点集合, A是动作节点集合, E是有向边集合,
能力依赖图的有向边有两种类型: 指向动作节点的边和指向能力节点的边. 有向边可以从能力节点和条件节点指向动作节点, 表示只有这些能力和条件前提都满足时该动作才能执行. 有向边也可以从动作节点指向能力节点, 表示该动作执行后产生的新能力.
如图2所示, dac_can_access(Uid, Gid, FileName, FileType, write)和se_can_access(Domain, FileName, write)是条件节点, control_process_code(proc(Uid, Gid, Domain))和control_file_data(FileName)是能力节点, WriteFile(FileName)是动作节点. 指向WriteFile(FileName)的三条边表示要对文件FileName进行写操作必须满足三个前提: (1) 控制了某个进程, 该进程安全上下文为proc(Uid, Gid, Domain); (2) DAC允许该安全上下文写文件FileName; (3) SEAndroid允许该安全上下文写文件FileName. 指向control_file_data(FileName)的边表示当对文件FileName进行写操作后产生的新的能力.
4.2.2 访问控制机制逻辑声明访问控制机制和系统状态信息一起构成了能力依赖图中的条件节点. 我们对自主访问控制和SEAndroid的类型强制访问控制机制进行逻辑声明. 权限提升攻击的攻击对象主要是文件和进程, 所以我们主要考虑与进程和文件相关的访问控制规则. 我们的研究目标在于发现SEAndroid访问控制策略的漏洞, 实际有些权限提升攻击确实不违反我们声明的SEAndroid访问控制规则, 例如利用内核的缓冲区溢出漏洞(如CVE-2017-13293[17])进行提权, 但这些攻击并不能通过修改SEAndroid安全策略来缓解, 这超出了我们的研究范围.
通常进程作为主体, 文件作为客体, 与之相关的权限包括读、写、执行. 由此, 以dac前缀代表自主访问控制, se前缀代表SEAndroid的类型强制访问控制, 我们声明的格式如下所示:
|
图 2 能力依赖图示例 |
dac_can_access(Uid, Gid, FileName, Mode): 检查自主访问控制下用户id、组id为Uid、Gid的主体是否能对FileName客体进行Mode操作;
dac_execv(OUid, OGid, NUid, NGid, Program) : 检查自主访问控制下用户id、组id为OUid、OGid的主体是否能通过执行Progrom程序克隆出一个用户id、组id为NUid、NGid的新进程;
se_domain_privilege(domain(Domain), type(Type), class(Class), op(Op)): 检查类型强制访问控制下域为Domain的主体能否对类型为Type、类别为Class的客体进行Op操作;
se_can_access(Domain, FileName, Mode): 检查类型强制访问控制下域为Domain的主体能否对文件FileName执行Mode操作;
se_execv(Domain, NewDomain, Type) : 检查类型强制访问控制下域为Domain的主体能否通过执行类型为Type的客体克隆出域为NewDomain的新进程;
privilege_enhancing(Uid, Gid, Domain, NewUid, NewGid, NewDomain): 检查产生新的进程后, 攻击者的能力是否有所提升. 检查的依据: 1)原Uid、Gid不为0(root)或1000(system)且用户id、组id发生改变; 2)原Domain的属性不为unconfineddomain且域发生改变.
4.2.3 能力集合逻辑声明由于进程和文件多被用来实现权限提升攻击, 我们关注与进程和文件相关的权限, 而攻击者获得的权限表述为对文件和进程具有的能力. 自主访问控制使用用户id和组id来标识主体, 类型强制访问控制使用域来标识进程, 因此我们使用proc(Uid, Gid, Domain)来描述进程的安全上下文. 针对Android的权限提升攻击中存在大量的远程攻击, 而远程攻击的前提是攻击者可以控制某个网络端口的输入. 由此, 我们声明的能力如下所示:
control_network_input(Port): 攻击者控制端口Port的输入, 并以此远程访问系统;
control_process_code(proc(Uid, Gid, Domain)): 攻击者控制一个用户id、组id为Uid、Gid, 域为Domain的进程;
control_file_data(FileName): 攻击者控制文件FileName的文件内容.
4.2.4 攻击动作与推导规则逻辑声明为了实现权限提升, 攻击者尝试执行不同的攻击动作来获取新的能力. 我们分析权限提升漏洞的利用方式, 得到如下影响系统安全性的操作, 即攻击动作:
WriteFile(FileName): 攻击者写FileName文件;
Execute(Program): 攻击者执行Program程序;
CompromiseNetwork(Pid, Port):攻击者将恶意制作的数据包通过端口Port发送到进程号为Pid的程序来攻陷该进程;
CompromiseRead(Pid, FileName): 攻击者恶意篡改进程号为Pid的程序读取的文件FileName的内容来攻陷该进程;
WaitExecute(Program): 攻击者等待正在被某个进程执行的程序Program以相同的安全上下文再次被执行;
HopeExecute(Program): 攻击者希望特权用户执行程序Program.
当一个攻击动作action执行时, 必须满足一定的前置条件pre-conditions, 该动作执行后, 攻击者将获取新的能力. 我们声明推导规则来描述这种能力转移关系.推导规则被声明为形如(pre-conditions, action, capability)的三元组. 我们声明的推导规则如表2所示.
Android访问控制子系统的一个重要功能是实现进程隔离, 即使某个脆弱程序被攻陷, 访问控制系统依然能够阻止权限提升攻击. 因此, 我们在声明推导规则时引入”what-if”分析, 我们假设每个可执行程序都可能存在漏洞, 都可能被攻击者利用执行任意代码.
|
|
表 2 推导规则逻辑声明 |
4.2.5 能力依赖图生成
要生成能力依赖图, 还需声明攻击者的初始能力和攻击目标. 攻击者分为远程攻击和本地攻击两种类型. 远程攻击者主要通过网络远程访问Android系统, 其初始能力被声明为control_network_input(Port), Port是系统开放的任意有效的端口号. 本地攻击者拥有一普通账户, 其初始能力被声明为control_process_code(Process), Process代表攻击者可以运行的进程. 攻击者的目标是获取root或system权限, 声明格式为control_process_code (proc(Uid, Gid, Domain)), Uid为0(root)或1000(system).
基于上述访问控制机制、能力集合、攻击动作集合、推导规则的逻辑声明, 我们按照算法1所示生成能力依赖图.
算法1. 能力依赖图生成算法
1) 在当前条件和能力下依据推导规则搜索能够执行的攻击动作;
2) 得到能够执行的攻击动作后, 依据推导规则计算该攻击动作执行后得到的新能力;
3) 构造(pre-conditions, action, new capability)日志记录;
4) 将步骤2中得到的新能力加入当前能力中;
5) 重复步骤1直到不再生成新的日志记录;
6) 添加pre-conditions指向action的边和action指向new capability的边.
4.3 路径分析器路径分析器以能力依赖图作为输入, 使用深度优先搜索算法(DFS)搜索所有从初始能力节点到目标节点的攻击路径, 如算法2所示. 算法首先遍历初始能力节点集合, 以每一个初始能力节点vi作为入口参数, 调用DFS, 将得到的路径集合Paths与攻击路径集合APS合并得到新的APS. DFS搜索过程中为减少不必要动作我们做了一些限制: (1) 攻击路径上不存在环路; (2) 攻击路径的长度不超过10; (3) 攻击路径的中间节点不含目标节点. 我们选择10作为攻击路径长度的阈值是因为基于我们的实验, 我们发现Android系统中大部分攻击路径长度是7和9, 如果减小阈值, 将损失大量攻击路径, 导致较高的漏报率; 增大阈值后. 新增的攻击路径数目只有几十条, 且这些新增的长攻击路径相比大量的短攻击路径, 对于攻击者来说工作量太大, 中间步骤多容易失败且容易被审计系统发现, 从而对攻击者而言缺乏吸引力. 而选择10作为攻击路径长度的阈值既可以满足性能需求, 也足够描述系统所承受的攻击面.
算法2. 攻击路径生成
输入: INS: 初始能力节点集合
GNS: 目标节点集合
输出: APS: 攻击路径集合
Function ATTACK_PATHS_GENERATION(INS, GNS)
1. APS
2. for all vi∈INS do
3. path ← null
4. DFS(vi, path)
5. APS ← APS ∪ Paths
6. end for
7. return APS
Function DFS(v, path)
1. if v in path then /*避免环路*/
2. return
3. end if
4. if path.length>10then
5. return
6. end if
7. path.push_back(v)
8. if v∈GNS then
9. Paths ← Paths ∪ path
10. else
11. for all node vi adjacent to v do
12. DFS(vi, path)
13. end for
14. end if
能力依赖图中存在大量的攻击路径, 因此我们引入攻击模式. 通过去掉攻击路径中的参数, 每一条攻击路径可以被抽象成一种攻击模式, 而每种攻击模式代表一类使用相同攻击动作的攻击路径.
5 实验结果分析针对权限提升攻击, 为检测不同版本的Android系统当前SEAndroid安全策略的安全漏洞, 我们利用我们的方法和工具对Android 6.0到Android 7.1这3个版本的SEAndroid安全策略进行评估与分析, 并将我们的实验结果与现有权限提升漏洞的利用方式进行比较以验证其有效性. 在本部分, 我们将介绍我们的实验环境和实验结果分析.
5.1 实验环境与步骤在我们的实验中, 系统状态信息在测试的Android系统上收集, 其余部分在安装有Ubuntu 16.04的机器上完成, 机器配置为Intel Core I7-6700 3.4 GHz, 8 GB内存.
我们的实验步骤如下:
(1) 信息收集: 将相关程序和脚本拷贝进Android系统并执行得到临时文件, 从Android系统中拷贝出临时文件和sepolicy, 执行相关脚本后得到系统中的访问控制元数据, 保存为Prolog谓词形式;
(2) Prolog推理: 根据Prolog推理规则和第一步生成的Prolog文件, 在XSB[18]逻辑推理引擎中执行相关查询, 进行逻辑推理, 记录推理轨迹, 生成能力依赖图;
(3) 攻击路径分析: 运行攻击路径分析程序, 以生成的能力依赖图作为输入, 生成图中的全部攻击路径, 并生成攻击路径抽象而成的攻击模式.
5.2 实验结果分析我们使用SETools[19]工具对多个Android版本的sepolicy二进制文件进行解析, 得到的类型、属性、allow规则、type_transtion规则的数目如表3所示. 从表3中, 我们可以发现, SEAndroid策略的类型、属性、allow规则、type_transtion规则的数目随着Android系统版本提升而增加. 从Android 6.0 到Android 7.0, 类型数目增加了23.2%, 属性增加了21.7%, allow规则增加了37.3%, type_transition规则增加了30.6%. 从Android 7.0 到Android 7.1, 类型数目增加了2.9%, 属性增加了3.6%, allow规则增加了3.3%, type_transition规则增加了7.0%.
|
|
表 3 不同Android版本的SEAndroid策略 |
我们的实验一共生成了8种攻击模式, 如下所示:
P1：control_network_input→CompromiseNetwork
→control_process_code→Execute
→control_process_code
P2：control_network_input→CompromiseNetwork
→control_process_code→WriteFile
→control_file_data→WaitExecute
→control_process_code
P3：control_process_code→Execute
→control_process_code
P4：control_process_code→WriteFile
→control_file_data→HopeExecute
→control_process_code
P5：control_process_code→WriteFile
→control_file_data→CompromiseRead
→control_process_code
P6：control_process_code→WriteFile
→control_file_data→CompromiseRead
→control_process_code→Execute
→control_process_code
P7：control_process_code→WriteFile
→control_file_data→CompromiseRead
→control_process_code→WriteFile
→control_file_data→HopeExecute
→control_process_code
P8：control_process_code→WriteFile
→control_file_data→CompromiseRead
→control_process_code→WriteFile
→control_file_data→CompromiseRead
→control_process_code
其中, P1、P2是远程攻击模式, P3到P8是本地攻击模式. 各Android版本中每种攻击模式对应的攻击路径数目如表4所示.
|
|
表 4 不同Android版本的攻击模式 |
从表4中, 我们可以看出Android 6.0有7种攻击模式, 823条攻击路径, Android 7.0 有6种攻击模式, 597条攻击路径, Android 7.1 有6种攻击模式, 312条攻击路径. Android 7.0 比 Android 6.0 多了一种远程攻击模式, 少了两种本地攻击模式, 整体攻击路径数量减少了27.4%. Android 7.1 与 Android 7.0的攻击模式很相似, 但攻击路径减少47.7%.
结合表3和表4, 我们可以得出结论: 随着Android版本的提升, SEAndroid安全策略也进行了更新. 新的Android版本的SEAndroid安全策略拥有更多的类型和规则, 与之对应的是系统中攻击路径的减少, 这说明系统受到了更强的约束和保护. 而CVE关于Android系统的漏洞统计[20–22]也说明了这一点: Android 6.0的漏洞数为558, Android 7.0的漏洞数为492, Android 7.1的漏洞数为228.
值得一提的是, 在对实验得到的攻击模式进行验证时, 我们发现P2模式中包含对SwiftKey的利用, 具体方式为: 攻击者通过发送恶意制作的数据包攻陷SwiftKey进程, 并改写一个可执行文件, 当该可执行文件被再次执行时, 攻击者获得特权进程. 而这种权限提升方式, 在实际系统中已经得到了验证[23]: 攻击者首先利用编号为CVE-2015-4640漏洞, 通过80端口向输入法应用程序SwiftKey发送精心构造的更新包, 然后利用CVE-2015-4641文件系统遍历漏洞使用该恶意更新包内的可执行文件将系统文件进行替换, 当该文件被执行时, 得到system权限进程. 这充分说明了我们方法的有效性.
6 相关工作目前, 有大量关于SELinux安全策略的研究: Jaeger等人设计实现了GOKYO[6,7]来分析安全策略中的各种冲突, 试图找到缺失或不正确的约束; Zanin和Mancini定义了形式化模型SELAC[8]来分析SELinux的安全策略配置; Kissinger和Hale设计实现了Lopol[9]来进行策略分析; Cheng等人设计实现了ACVAL[10]来评估和比较不同操作系统访问控制机制提供的保护质量; Han[11]等人提出一种基于能力依赖图和MaxSAT的访问控制安全策略配置自动化强化方法. 但这些都没有将SEAndroid的特定方面考虑在内.
Wang等人设计实现了EASEAndroid, EASEAndroid[12]提出了一种半监督式机器学习方法来改进SEAndroid安全策略. 因为Android的持续更新和不断有新的攻击出现, SEAndroid安全策略需要持续改进. EASEAndroid提取大规模审计日志中的相关信息, 利用此信息构建访问模式, 以AOSP的参考策略和自定义少数恶意访问模式作为初始知识库, 利用半监督的机器学习方法对访问模式进行聚类, 根据聚类结果, 将良性访问模式转换为allow规则, 恶意访问模式转换为neverallow规则. 但是获得这个数据量的审计日志是很困难的, 因为它需要收集来自数百万个Android设备的日志文件, 而这可能涉及用户隐私. 并且默认情况下, 审计日志只记录被策略拒绝的系统层的操作, 对太过宽松的策略, 恶意访问可能被允许而没有记录, 对应用层的操作更是没有涉及. 最后生成的访问策略的安全性也有待考证.
Wang等人[13]实现了SPOKE来识别过于宽松的策略规则. SPOKE从Android系统功能测试中自动收集用户层的功能踪迹和内核层的访问模式, 根据pid、uid和带时间戳的包名, 在访问模式与功能踪迹间建立关联, 并将结果导入数据库; 查询数据库, 将不能与数据库中访问模式匹配的策略规则识别为过于宽松的策略规则. SPOKE的缺点是依赖于通常不完整的应用程序功能测试, 而且功能测试中也可能包含不恰当的访问.
7 结语在本文中, 我们结合自主访问控制机制提出一种基于能力依赖图的SEAndroid安全策略分析方法. 我们对SEAndroid访问控制机制的实现方法进行分析, 同时与SELinux进行比较, 构造系统信息和安全策略的抽取工具, 并对抽取的信息进行逻辑声明. 基于系统信息、访问控制规则、推导规则等的逻辑声明, 我们生成了能力依赖图, 通过深度优先搜索能力依赖图得到了攻击路径. 我们设计实现了原型系统, 并对多个版本Android系统的SEAndroid安全策略进行了评估与分析, 我们发现随着Android版本的提升, SEAndroid安全策略也进行了更新, 对系统提供了更强的约束和保护. 值得一提的是我们在实验中得到了一种已在实际系统中得到验证的攻击模式. 在未来工作中, 我们将对更广泛的Android手机固件进行试验, 发现其中的攻击模式, 实施进一步的对比与验证, 并尝试对引起权限提升漏洞的安全策略进行自动化定位和修复.
| [1] |
Smalley S, Craig R. Security enhanced (SE) Android: Bringing flexible MAC to Android. NDSS, 2013, 310: 20-38. |
| [2] |
Loscocco P, Smalley S. Integrating flexible support for security policies into the Linux operating system. Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference. Boston, MA, USA. 2001. 29–42.
|
| [3] |
Security-Enhanced Linux in Android. https://source.android.com/security/selinux.
|
| [4] |
CVE-2015-4640. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4640.
|
| [5] |
CVE-2015-4641. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4641.
|
| [6] |
Jaeger T, Zhang XL, Edwards A. Policy management using access control spaces. ACM Transactions on Information and System Security, 2003, 6(3): 327-364. DOI:10.1145/937527 |
| [7] |
Jaeger T, Sailer R, Zhang X L. Analyzing integrity protection in the SELinux example policy. Proceedings of the 12th Conference on USENIX Security Symposium. Volume 12. Washington, DC, USA. 2003. 5.
|
| [8] |
Zanin G, Mancini LV. Towards a formal model for security policies specification and validation in the selinux system. Proceedings of the Ninth ACM Symposium on Access Control Models and Technologies. Yorktown Heights, NY, USA, 2004, 136-145. |
| [9] |
Kissinger A, Hale JC. Lopol: A deductive database approach to policy analysis and rewriting. Proceedings of the Second Annual Security Enhanced Linux Symposium. Baltimore, MD, USA. 2006.
|
| [10] |
Cheng L, Zhang Y, Han ZH, et al. Evaluating and comparing the quality of access control in different operating systems. Computers & Security, 2014, 47: 26-40. |
| [11] |
Han ZH, Cheng L, Zhang Y, et al. Operating system security policy hardening via capability dependency graphs. Lopez J, Wu YD. Information Security Practice and Experience. Cham: Springer, 2015. 3–17.
|
| [12] |
Wang RW, Enck W, Reeves DS, et al. EASEAndroid: Automatic policy analysis and refinement for security enhanced Android via large-scale semi-supervised learning. Proceedings of the 24th USENIX Conference on Security Symposium. Washington, DC, USA. 2015. 351–366.
|
| [13] |
Wang RW, Azab AM, Enck W, et al. SPOKE: Scalable knowledge collection and attack surface analysis of access control policy for security enhanced Android. Proceedings of the 2017 ACM Asia Conference on Computer and Communications Security. Abu Dhabi, United Arab Emirates. 2017. 612–624.
|
| [14] |
Badger L, Sterne DF, Sherman DL, et al. A domain and type enforcement UNIX prototype. Proceedings of the 5th Conference on USENIX UNIX Security Symposium. Volume 5. Salt Lake City, UT, USA. 1995. 12. 47–83.
|
| [15] |
Sandhu RS, Coyne EJ, Feinstein HL, et al. Role-based access control models. Computer, 1996, 29(2): 38-47. DOI:10.1109/2.485845 |
| [16] |
Sandhu RS. Lattice-based access control models. Computer, 1993, 26(11): 9-19. DOI:10.1109/2.241422 |
| [17] |
CVE-2017-13293 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13293. [2017-08-23].
|
| [18] |
Sagonas K, Swift T, Warren DS, et al. The XSB system version 3.0-volume 1: Programmer’s manual, Volume 2: libraries. Interfaces, and Packages. 2006.
|
| [19] |
SETools. https://github.com/TresysTechnology/setools. [2017-11-10].
|
| [20] |
Google Android version 6.0: Security vulnerabilities. https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-19997/version_id-187788/Google-Android-6.0.html.
|
| [21] |
Google Android version 7.0: Security vulnerabilities. https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-19997/version_id-201744/Google-Android-7.0.html.
|
| [22] |
Google Android version 7.1.0: Security vulnerabilities. https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-19997/version_id-204495/Google-Android-7.1.0.html.
|
| [23] |
Remote Code Execution as System User on Samsung Phones. https://www.nowsecure.com/blog/2015/06/16/remote-code-execution-as-system-user-on-samsung-phones/.
|