
一般来说,类型强制规则(缩写为
rule
)
符合
“allowdomaintype
:
classpermission“
,它定义了系统中主体的可允许操作。特别地,
域
字段指定
主题的标签(例如,过程),
类型
指示对象的标签(例如,文件
和套接字),
类
是对象的类,
权限
表示
对对象执行的特定操作。例
如,规则
“allow untrusted_app app_data_file
:
file {open read};”
允许
标 记 为
“untrusted_app”
的 所 有 进 程 打 开 并 读 取 标 记 为
“app_data_file”
的普通文件。 所有
规则都是由系统开发人员编写
的,并保存在源代码树中的 *.te文件中。
为了正确有效地编写和管理这些规则
,
SEAndroid
中定义的大
多数类型都有几个属性。例如,
untrusted_app
具有多个属性,包
括
do- main
、
appdomain
和
netdomain
,分别指示不可信
app
是进
程、app进程和具有网络访问的进程。由属性定义的规则对于
具有该属性的所有
主体或对象都有效。策略编写者还可以使用宏
来提供可重用的语句片段 例如
,rw_file_perms是一个代表权限
列 表 的 宏 -getattr open read ioctl lock map append write ,
binder_use
(
domain
)
可以在目标域的单行中生成与Binder IPC
使用相关的所有规则。此外,在
SEAndroid
的源代码树中有两种类型
的命令式规则
-
允许规则和从不允许规则
。 neverallow
规则
不会
被编译到设备中,但当存在
违反
neverallow
条目的允许规则
时,它将中断编译。 这些规则主要用于
避免引入不规范的规
则。
这些允许 *.te文件中的规则最终编译成固件
映像,并在系统启动
时初始化。
SEAndroid
将拒绝策略中未明确允许的所有访问尝试,
即使进程以root身份运行:
uid=0(root)gid=0(root)groups=. context=u:r:untrusted_app:s0:c512,c768
11-06 06:41:49.193 2810 2810 W ls:type=1400 audit(0.0:19):avc:denied
{read}
for name="/”dev=“sda43”ino=2 scontext=u:r:untrusted_app:s0:c512,c768
tcontext=u:object_r:rootfs:s0 tclass=dir permissive=0
2.2
政策多样性
从以下角度来看,政策规则可能会有很大
版本多样性。
SELinux
版本和
SEAndroid
版本都用于指示策略的状态。从
SELinux
版本
的角度来看,当新的语法特性添加到策略中时,它会发生变化这
可能会导致策略语法以及二进制策略中的文件结构发生变化例
如,
Android 5
使用
26.0
的
SELinux
版本,而
Android 6
使用
30.0
,
这
导致了一些宏和保留字的变化。
从
SEAndroid
版本的角度来看,它
与Android的版本同步它
表示 随着 操 作 系统 的发 展 策略 的变化 例如,
在
27
版之前的
SEAndroid
策略规则中, 所有进程都可以通 过 直接打开字符
device
:
“allow domain ashillary_device : chr_file rw_file_perms” 来 访 问
ashillary设备
。然而,在
Android 9和SEAndroid 28上,进程必须
使用本地API来
相同目的,并且这样的规则被修改为
“允许域ash-缓存_设备:chr_filegetattrread
ioctllockappendwrite”
。 因此
,在Android9中,从普通用户级进程打开/dev中的
ashcodedevice将被拒绝。事实上,随着Android版本的发展,官
方政策通常会发生很大变化
政策形式多样。
不同文件格式的策略
在呈现方式上有所不同。以
下不同策略文件中的代码片段
显示了如何以不同的样式表示一个
规则。
allow{ appdomain -isolated_app } app_data_file:file r_file_perms
allowbase_typeattr_97 app_data_file(file(getattr open read ioctl lock map))
allowbluetooth app_data_file:file getattr open read ioctl lock map;
allowplatform_app app_data_file:getattr open read ioctl lock map;
allowuntrusted_app app_data_file:file getattr open read ioctl lock map;.
AOSP
中的规则保存在按域分类的*.te文件它们大多用宏、属
性和逻辑符号(如
“*”
表示所有,
“-”
表示异常)编写,而设备中
内置的二进制策略可以通过
setools[11]
解压缩源代码中属性定义的
相应规则在
setools
的解压缩结果中可以表示为多个条目。这意味
着二进制策略和源代码策略之间的规则粒度可能不同此外,
neverallow
规则
不会编译到二进制策略中。
随着
Android8.0
中
Project Treble [8]
的引入,一种名为通用中间语
言(
CIL
)的新策略格式被用作 *.te策略文件和二进制策略文件之
间的中间表示
-
除了编译的二进制策略,
设备还包含多个编译的
CIL
文
件。
CIL
文件中定义的规则保持
源代码(*.te文件)中定义的
allow和neverallow规则的顺序和形状。因此,CIL文件包含
的信息比使用
setools
从二进制策略
中获得的信息多得多
。例如,上面
提到的属性
base_typeattr_97
被分配给除了isolated_app之外的所有
应用级别类型,isolated_app保留了否定表达式的形状。
政策多义性。由于属性定义的自定义,*.te或二进制
策略文件中
具有相同语法的规则在不同的设备中可能具有不同的含义。例如,
属
性hal_audio的定义在Pixel设备
和某些第三方设备之间可能不同,
导 致 以 下 规 则 可 能 具 有 不 同 的 含 义 :
“allow hal_audio
audio_device
:
chr_file ioctl“
这样的规则在
AOSP
中是合理的,
但 在 某 些 第 三 方 设 备 中 , 属 性
hal_audio
被 额 外 分 配 给 域
hal_ir_default
和域
hal_irsi_default。 这两个域
主要分配给与红外
相关的服务器进程。 它将授予
比原始规则更多的权限(如第6.2节
所示)。
3
问题陈述
在这一部分中,我们提出了本文要解决的问题策略的
定制可能
会给
SEAndroid
设备带来严重的安全风险和破坏
性影响。图
1
显示了
一个说明性示例,说明由于对原始策略的不正确添加,可能会利
用一个漏洞具体而言,
在联发科(
MTK
)存储的驱动程序中发现了
越界访问漏洞(
CVE-2015-6637
)。驱动程序公开一个设备节点
/dev/misc-sd
由
misc_sd_device
标记,并由原始策略控制
,其中只有
vold
域可以访问易受攻击的进程