SEAndroid那点事
概述
Android平台的基础是Linux内核，android每个应用都运行在自己的沙盒中，在Android4.3之前的版本中，android会给每一个应用分配一个独一无二的ID，所以每个应用都有自己的权限边界，从Android4.3开始，android引入了SELinux，进一步定义Android应用沙盒的边界，运行在单独的进程中，所以每个应用都有自己的权限边界，系统负责管理 Android应用对资源的访问权限。
DAC和MAC
DAC–自主访问控制
在DAC中有所有权的概念，就是说资源的所有者或者创建者拥有对相应资源的访问权限。
root可以访问和操作一切，是一种传统的Linux的安全模式；
MAC–强制访问控制
MAC(Mandatory Access Control)强制执行访问控制，即使是root权限用户也将接受MAC的权限检查，root进程与其他进程没有任何区别，
MAC具体有两种模式：
- 宽容模式：不会强制执行访问控制，但是会被logcat上会打印出log提示。
打开方式：
adb shell setenforce 0强制模式：强制执行访问控制，而且logcat也将打印出log提示。
打开方式：
adb shell setenforce 1DAC和MAC的区分和联系
DAC的主体是真实有效的用户和组ID，MAC的主体是安全上下文，两者的UID是各自独立的。
DAC的访问控制模式是rwxrwxrwx，MAC的访问控制模式是user:role:type。
- 内核的安全机制是DAC与MAC共存的。先进行DAC检查然后进行MAC检查。如图所示：
流程解读：
- 一个进程向系统发出对某个文件操作请求时，会先进行linux传统的安全机制检查（DAC）；
- 如果DAC检查失败，则直接失败；
- 如果DAC检查通过，则会进行强制控制检查（MAC）；
- MAC检查失败，则打印avc：denied 信息并终止操作请求；
MAC检查成功，则允许操作请求；
- MAC校验流程
MAC校验流程解读：
一个进程向系统发出对某个文件操作请求，到MAC校验时会将请求放入SecurityServer对象中申请操作；
SecurityServer会从PolicyDB中load权限列表；
系统进行权限校验；
权限允许则进程可进行相应操作；
权限拒绝则打印avc:Denied信息提示无权限，avc:access vector cache；
权限的添加策略
SecurityContext
SEAndroid通过type（Security Context）来决定应用的访问权限，Security Context格式：
User:Role:Type:SecurityLevelUser：用户
Role：角色
Type：安全上下文 – 决定权限
SecurityLevel：安全级别
te文件
在*.te中书写主体的SecurityContext规则：
type subject, attributes;
allow domains types:classes permissionssubject：主体
attributes：属性
domain:一个进程或者一组进程
type：一个对象（例如，文件、套接字）或一组对象的标
class：要访问的对象（例如，文件、文件夹）的类型
Permission：操作
列如在system_app.te中添加主体为data_file的规则：
type data_file, file_type, data_file_type;
allow system_app data_file:dir { remove_name search open read write add_name create getattr setattr };
...添加主体的2个方法
1、缺啥补啥法：
2、audit2allow自动生成
- 先抓取需要的avclog文件：
adb shell dmesg | grep avc | grep "pid=***" > avc.txt- 通过audit2allow自动生成te代码：
audit2allow -i avc.txt > avc.te生成te文件后，将代码拷贝到相应的te文件中但是这个方法有个权限，有可能扩大权限范围。
file_contexts
在file_contexts中添加客体SecurityContext规则，添加方式列如：
/data/data(/.*)? u:object_r:data_file:s0案例
本人在开发语音待机唤醒过程中，遇到以下场景：
1：三方A通过用户三次语音训练会在data/trigger文件夹下产生amodel.bin模型文件；
2：生成amodel.bin模型后语音助手会通知三方B去load这个模型，load成功后开启三方B芯片监听模式；
在这个案例中由一个三方产生文件，又由另一个三方去读取这个文件，而且生成的文件是在data目录下，即使是把amodel.bin模型权限设置为777时也无法访问；
解决该问题需要以下几步：
1、在android\inti.rc文件中创建trigger文件夹并将DAC权限设置为0644，首先解决DAC的权限访问；
post-fs-data
mkdir /data/trigger 0644 system system2、主体定义：在对应的android\vendor\sepolicy\common\system_app.te文件中添加：
type voicedata_file, file_type, data_file_type;
allow system_app data_file:dir { search open read create};
allow system_app data_file:file { open read write create};3、客体定义：在android\vendor\sepolicy\common\file_contexts文件中添加：
/data/trigger(/.*)? u:object_r:data_file:s04、编译验证,由于policy修改需要重新打包boot.img、system.img：
make bootimage systemimage总结
在写上面这个案例的时候，回顾了一下解决这个问题的过程，可以说一路荆棘，之前并不了解SEAndroid这东东，所以花了比较大的时间才把解决问题的重心转移到解决SEAndroid这个问题上，所以做ROM开发，一定要从系统全局去考虑问题引起的具体原因，对症下药，解决办法的方法往往都很简单，难点是发现问题出现的原因；
学习资料
https://source.android.com/devices/tech/security/selinux/index.html