Selinux安全机制

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