Android中的SELinux
SELinux （Security Enhanced Linux）是由美国NSA（国安局）和 SCC 开发的 Linux 的一个扩张强制访问控制安全模块，目的是最大限度减少系统中服务进程可访问的资源。Google 在 Android 4.4 上正式添加以 SELinux 为基础的系统安全机制，命名为SEAndroid。SEAndroid 在架构和机制上与 SELinux 完全一样，基于移动设备的特点，SEAndroid 的只是所以移植 SELinux 的一个子集。
DAC与MAC
自主访问权限（DAC）
当程序要操作文件时，系统根据程序的 Owner/Group，对比文件的权限，若通过权限检查，则可操作文件，但可能造成问题：
- root 具有最高权限，若某程序属于root，则该程序可操作系统的任何文件
- 使用者可利用程序来变更文件的权限
强制访问控制（MAC）
以进程为主体，任何进程想在系统上干任何事情，都必须在《安全策略文件》中赋予权限。
- TEAC（Type Enforcement Accesc Control）：一般用TE表示，是MAC的基础管理思路。根据Security Context中的 type 进行权限审查, 审查 subject type 对 object type 的某个class 类型中某种 permission 是否具有访问权限
- Role Based Accesc Control：MAC的高级管理思路基于角色控制，RBAC 是基于 TE 的
模式
- Enforcing：强制模式：SELinux在运行中，且已经开始限制domain/type之间的验证关系
- Permisssive：宽容模式：SELinux在运行中，如果验证不正确会发出警告
- Disabled：关闭模式，SELinux并没有实际运行
//获取SeLinux模式
adb shell getenforce
//设置SeLinux模式为Enforcing（只允许Enforcing和Permissive之间切换）
adb shell setenforce 1
//设置SeLinux模式为Permisssive
adb shell setenforce 0
sContext
组成
SELinux 安全策略是建立在对象安全上下文的基础上的，对象可以分为两种：
- 主体（Subject）：通常指进程。
- 客体（Objcet）：指通常要访问的资源，如文件、进程、socket等。
在 SELinux 中，每种东西都会被 Policy 赋予一个安全属性，官方说法叫做 Security Context（sContext），sContext 是一个字符串。根据 SELinux 规范，完整的 sContext 字符串主要由三个部分组成：user:role:type[:range]
- user：Android中只定义了一个SELinux用户，即
u - role：一个user可以属于多个role，不同role具有不同权限，即MAC的高级管理思路，基于角色控制（RBAC），Android中定义主体的role为
r，客体等role为object_r - type：主体的Type就是Domain，MAC的基础管理思路Type Enforcement Access Control（简称TEAC，一般用TE表示），也是 Android 中最主要的手段。
- range：MLS 的等级
可以通过命令ps -Z查看进程的 sContext，通过命令ls -Z查看文件的 sContext
定义
定义sContext标准格式为：resource sContext，其都定义在type_contexts当中，例如file的定义在 file_contexts 中，service定义在 service_contexts 中，property 定义在property_contexts中
//file_contexts示例，指定 adb_keys 文件的 sContext 为 u:object_r:adb_keys_file:s0
/adb_keys u:object_r:adb_keys_file:s0
//service_contexts示例，指定名为 account 的 service 的 sContext 为 u:object_r:account_service:s0
account u:object_r:account_service:s0
Attribute and Type
SELinux 中每一个进程或者文件都对应一个type, 而每一个type 都对应有一个或几个attribute。属性类似一个组，type 关联属性之后， 新增的 type 就可以加入到这个属性组中，这个属性(组)拥有的权限， 新增的type也就自然拥有了这个权限)。
- 定义type，type的定义通常分散在各个te文件中（
system/sepolicy/*/*.te）
//type 类型名称;
//例如
type domain;
- 定义别名
//typealias 类型名称 alias 别名;
//例如
typealias mozilla_t alias netscape_t;
- 定义attribute，attribute定义在
system/sepolicy/*/attributes文件中
attribute XXXX;
//例如
attribute domain;
- type与attribute关联，一个type可以关联一到多个attribute
//app_data_file类型，关联 file_type、data_file_type 两个属性
type app_data_file, file_type, data_file_type
Class
SELinux 对于不同的资源类型，定义了不同的class，比如普通的file、socket等等，每一个 class 都有相对应的 permissions， 比如 file 就有 read, write, create, getattr, setattr, lock, ioctl 等等。这些相关的class、permissions都定义在system/sepolicy/*/access_vectors文件中
common file
{
ioctl
read
write
... ...
}
common socket
{
connect
listen
accept
...
}
定义完之后，在对应的 security_classes 文件（system/sepolicy/*/security_classes）中声明定义的classes
class file
class dir
class fd
权限集
在system/sepolicy/public/global_macros文件中有定义，例如：
define(`w_file_perms`,`{open append write lock map}`)
授权
//Domain：主体，进程类型
//Type：客体，对象类型
//Class：客体的class。
//Permission：要执行的操作（例如，读取、写入）。
allow domains types:classes permissions;
allow domain {type1 type2}:file execute;
allow {domain1 domain2} {type1 type2 type3}:file {execute read };
allow domain type:{ file dir } { read getattr };
allow：表示容许主体对客体执行许可的操做。
neverallow：表示不容许主体对客体执行制定的操做。
auditallow： 表示容许操做并记录访问决策信息。
dontaudit：表示不记录违反规则的决策信息，切违反规则不影响运行。
App分类
SEAndroid将app划分为主要三种类型(根据user不同，也有其他的domain类型)
untrusted_app：第三方app，没有Android平台签名，没有system权限platform_app：有android平台签名，没有system权限system_app：有android平台签名和system权限untrusted_app_25：第三方app，没有Android平台签名，没有system权限
示例
- 错误说明
//访问主体是 demo_service，对应的 sContext 的 type 是 system_server //对default_android_service，类型是service_manager，缺少 add 权限 avc: denied { add } for pid=9981 uid=1000 name=demo_service scontext=u:r:system_server:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager permissive=0 - 解决修复
//在 service_contexts 文件中为 demo_service 定义 sContext demo_service u:object_r:demo_service_type:s0 //在 te 文件中定义 demo_service 的 type，且关联 app_api_service、system_server_service、service_manager_type 属性 type demo_service_type, app_api_service, system_server_service, service_manager_type; //在 te 文件中进行授权 allow system_server demo_service_type:service_manager {add find};