1.Selinux安全机制简介
Selinux是Google在Android 4.4上正式推出的一套以SELinux为基础于核心的系统安全机制。而SELinux则是由美国NSA（国安局）和一些公司（RedHat、Tresys）设计的一个针对Linux的安全加强系统。
NSA最初设计的安全模型叫FLASK，全称为Flux Advanced Security Kernel（由Uta大学和美国国防部开发，后来由NSA将其开源），当时这套模型针对DTOS系统。后来，NSA觉得Linux更具发展和普及前景，所以就在Linux系统上重新实现了FLASK，称之为SELinux。
Linux Kernel中，SELinux通过Linux Security Modules实现。在2.6之前，SElinux通过Patch方式发布。从2.6开始，SELinux正式入驻内核，成为标配。
虽然SELinux已在Linux内核中存在了近十年，但至今仍有很多管理员由于担心其配置的复杂性而弃之不用。虽然许多Linux管理员在他们的Linux服务器中禁用SELinux来避免在安装应用程序时对它进行配置，但在Linux安全性方面SELinux是一个非常有用的工具。
2.SELinux Policy语言介绍
在android里面，有两个类型，一种是文件，一种是进程。针对这两种类型，我们可以先来看看他们的不同。
【1】在android上面，adb shell之后进入手机，ps -Z可以查看当前进程所拥有的selinux的权限。
u为user的意思。SEAndroid中定义了一个SELinux用户，值为u。
r为role的意思。role是角色之意，它是SELinux中一种比较高层次，更方便的权限管理思路，即Role Based Access Control（基于角色的访问控制，简称为RBAC）。简单点说，一个u可以属于多个role，不同的role具有不同的权限。
init，代表该进程所属的Domain为init。对进程来说，Type就是Domain。比如init这个Domain有什么权限，都需要通过allow语句来说明。
S0和SELinux为了满足军用和教育行业而设计的Multi-Level Security（MLS）机制有关。简单点说，MLS将系统的进程和文件进行了分级，不同级别的资源需要对应级别的进程才能访问。
【2】在android上面，adb shell之后进入手机，ls -Z可以查看文件所拥有的selinux的权限。
u：同样是user之意，它代表创建这个文件的SELinux user。
object_r：文件是死的东西，它没法扮演角色，所以在SELinux中，死的东西都用object_r来表示它的role。
rootfs：死的东西的Type，和进程的Domain其实是一个意思。它表示root目录对应的Type是rootfs。
s0：MLS的级别。
总结进程和文件的SContext的文件格式如下：
user:role:type[:range]
注意，方括号中的内容表示可选项。s0属于range中的一部分。下文再详细介绍range所代表的Security Level相关的知识。SContext的核心其实是前三个部分：user:role:type。
MAC基本管理单位是TEAC（Type Enforcement Accesc Control），然后是高一级别的Role Based Accesc Control。RBAC是基于TE的，而TE也是SELinux中最主要的部分。
3.TE文件
在Android的源码中对应的TE文件所在的路径为/home/linux/fspad-733/androidL/external/sepolicy
这些.te文件中有allow的语句，咱们来具体的分析一下这个语句的功能
allow netd proc:file write
这条语句的语法为：
allow：TE的allow语句，表示授权。除了allow之外，还有allowaudit、dontaudit、neverallow等。
netd：source type。也叫subject，domain。
proc：target type。它代表其后的file所对应的Type。
file：代表Object Class。它代表能够给subject操作的一类东西。例如File、Dir、socket等。在Android系统中，有一个其他Linux系统没有的Object Class，那就是Binder。
write：在该类Object Class中所定义的操作。
5.问题的解决
参考例子如下：
audit(0.0:67): avc: denied { write } for path="/dev/block/vold/93:96" dev="tmpfs" ino=1263 scontext=u:r:kernel:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file permissive=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;
【1】Selinux设备文件权限解决办法
[53692.570392] type=1400 audit(12565266.940:42): avc: denied { read write } for pid=10794 comm="m.example.hello" name="led1" dev="tmpfs" ino=39430 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=0
分析过程：
缺少什么权限： read write
谁缺少权限： scontext=u:r:untrusted_app:s0 untrusted_app
对那个文件缺少权限：tcontext=u:object_r:device:s0 device
什么类型的文件：tclass=chr_file chr_file
把缺少的权限添加上去，添加的过程如下。
cd external/sepolicy:
1.修改file_contexts
/dev/led1 u:object_r:led1_device:s0
2.修改device.te
type led1_device, dev_type;
3.修改 untrusted_app.te
allow untrusted_app led1_device:chr_file rw_file_perms;
添加好了之后重新编译Android的源码，烧写system.img和boot.img
【2】Selinux服务权限解决办法
E/SELinux ( 128): avc: denied { add } for service=led scontext=u:r:system_server:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager
问题分析：从第一个问题中我们分析在执行ioctl这个函数时返回了一个空的指针，从第二个查看的内容中我们分析到的问题时led这个内容没有Selinux权限。
分析过程：
缺少什么权限： { add }权限，
谁缺少权限： system_server
对哪个文件缺少权限：default_android_service
什么类型的文件： service_manager
解决方法：system_server.te
allow system_server default_android_service: service_manager add;
把缺少的权限添加上去，添加的过程如下。
进入fspad-733/androidL/external/sepolicy中
1.在service.te文件中添加
type led_service, service_manager_type;
2.在service_contexts文件中添加
led u:object_r:led_service:s0
3.在system_server.te文件中添加
allow system_server led_service: service_manager add;
添加好了之后重新编译Android的源码，烧写system.img和boot.img