SEAndroid 浅谈

最新推荐文章于 2024-08-16 10:59:50 发布

韩半仙

最新推荐文章于 2024-08-16 10:59:50 发布

阅读量4k

点赞数 2

Android 专栏收录该内容

157 篇文章 10 订阅

订阅专栏

1 绪论

在引入SEAndroid之前，Android的安全处理机制分为应用程序和内核两个部分。应用程序部分安全机制就是通常所说的permission,相应的权限在AndroidManifest.xml中设置，当应用需要使用系统服务的时候会提示用户来确认。内核部分的安全机制就是传统的Linux UID/GID机制。在Linux UID/GID机制中，文件的权限控制在所有者的手中。因此，这种权限控制方式就称为自主式的，正式的英文名称为Discretionary Access Control，简称为DAC。

在理想情况下，DAC机制是没有问题的。然而，在现实中，会产生严重的安全问题。例如，一个用户可能会不小心将自己创建的文件的权限位错误地修改为允许其它用户访问。如果这个用户是一个特权用户，并且它错误操作的文件是一个敏感的文件，那么就会产生严重的安全问题。这种误操作的产生方式有三种：

1. 用户执行了错误的命令

2. 负责执行用户命令的程序有BUG

3. 负责执行用户命令的程序受到攻击

在访问控制模型中，与DAC机制相对的是MAC机制。MAC的全称是Mandatory Access Control，翻译为强制访问控制。在MAC机制中，用户、进程或者文件的权限是由管理策略决定的，而不是由它们自主决定的。SEAndroid就属于MAC机制。

Android 5.0之后内核的安全机制是DAC与MAC共存的。先进行DAC检查然后进行MAC检查。如图所示：

2 关闭SELinux的两种方法

2.1 永久方法 – 需要重启设备

修改/etc/selinux/config文件中设置SELINUX=disabled ，然后重启设备。

2.2 临时方法 – 设置系统参数

使用命令setenforce 0

附：

setenforce 1 设置SELinux 成为enforcing模式
setenforce 0 设置SELinux 成为permissive模式

3 用户空间SEAndroid介绍

在用户空间中，SEAndroid包含有三个主要的模块，分别是安全上下文（Security Context）、安全策略（SEAndroid Policy）和安全服务（Security Server）

3.1 安全上下文

SEAndroid是一种基于安全策略的MAC安全机制。这种安全策略又是建立在对象的安全上下文的基础上的。这里所说的对象分为两种类型，一种称主体（Subject），一种称为客体（Object）。主体通常就是指进程，而客体就是指进程所要访问的资源，例如文件、系统属性等

安全上下文的格式为：user:role:type:sensitivity

3.1.1 查看文件的安全上下文

adb shell ls -Z

如截图所示，所有文件的user都是u，role都是object_r

文件factory_init.rc的Scontext为u:object_r:rootfs:s0

3.1.2 查看进程的安全上下文

adb shell ps -Z

如截图所示所有进程的user都是u，role都是r

进程init的Scontext为u:r:init:s0

3.1.3安全级别

安全级别是由敏感性（Sensitivity）和类别（Category）两部分内容组成的，格式为“sensitivity[:category_set]”
“s0:c0,c1”表示的就是Sensitivity为s0、Category为c0和c1的一个安全级别。

3.1.4 Type

在SEAndroid中，我们通常将用来标注文件的安全上下文中的类型称为file_type，而用来标注进程的安全上下文的类型称为domain，并且每一个用来描述文件安全上下文的类型都将file_type设置为其属性，每一个用来进程安全上下文的类型都将domain设置为其属性。

3.1.5 安全上下文定义的文件所在目录及文件

所在目录：external/sepolicy

包含的文件：

mac_permissions.xml（app进程）

file_contexts（系统文件）

genfs_contexts

initial_sid_contexts

port_contexts

property_contexts（系统属性）

seapp_contexts（app数据文件）

service_contexts

3.2 安全策略

安全策略是在安全上下文的基础上进行描述的，也就是说，它通过主体和客体的安全上下文，定义主体是否有权限访问客体。
SEAndroid安全机制主要是使用对象安全上下文中的类型来定义安全策略，这种安全策略就称Type Enforcement，简称TE。在external/sepolicy目录中，所有以.te为后缀的文件经过编译之后，就会生成一个sepolicy文件。这个sepolicy文件会打包在ROM中，并且保存在设备上的根目录下，即它在设备上的路径为/sepolicy。
下面我们看一下.te文件的内容：

system_app.te

allow system_app system_data_file:dir create_dir_perms;

允许具有system_app 属性的进程在具有system_data_file属性类型的文件夹中创建文件。

SEAndroid app分类：

app.te

isolated_app.te

platform_app.te（具有android platform签名，没有system权限的app）

system_app.te（具有android platform签名与system权限的app）

untrusted_app.te（第三方app, 不具有android platform签名和system权限）

3.3 Security Server

用户空间的Security Server主要是用来保护用户空间资源的，以及用来操作内核空间对象的安全上下文的，它由应用程序安装服务PackageManagerService、应用程序安装守护进程installd、应用程序进程孵化器Zygote进程以及init进程组成。其中，PackageManagerService和installd负责创建App数据目录的安全上下文，Zygote进程负责创建App进程的安全上下文，而init进程负责控制系统属性的安全访问。

4 RBAC和constrain

由前文可知，.te文件内部包含各种allow, type等语句，这些都是TEAC(type enforcement access control)，属于SELinux MAC中的核心组成部分。

在TEAC之上，SELinux还有一种基于Role的安全策略，也就是RBAC（role based access control）。

e.g.

constrain file write (u1 == u2 and r1 == r2)

这句话表示只有source和targe的user相同，并且role也相同，才允许write file

5 具体案例分析

原则是"缺什么补什么"

5.1 案例一

audit(0.0:67):avc: denied {write } forpath="/dev/block/vold/93:96" dev="tmpfs" ino=1263scontext=u:r:kernel:s0tcontext=u:object_r:block_device:s0tclass=blk_filepermissive=0

分析过程：

缺少什么权限： { write }权限，

谁缺少权限： scontext=u:r:kernel:s0，

对哪个文件缺少权限：tcontext=u:object_r:block_device

什么类型的文件： tclass=blk_file

解决方法：kernel.te

allow kernel block_device:blk_file write;

5.2 案例二

03-23 10:15:40.290 1422 1422 W Pipe_Write_Hand:type=1400 audit(0.0:79): avc: denied { ioctl } forpath="socket:[19308]" dev="sockfs" ino=19308scontext=u:r:system_app:s0 tcontext=u:r:bluetooth:s0 tclass=unix_stream_socketpermissive=0

03-23 10:15:40.301 1280 1422 W System.err: Java.io.IOException: Permission denie

解决方法：

在system_app.te里添加 bluetooth_domain(system_app)

原因： bluetooth.te中对bluetooth_domain属性赋予了权限

allow bluetoothdomain bluetooth:unix_stream_socket { getopt setopt getattr read write ioctl shutdown};