selinux 介绍

[   61.288030]   type=1400 audit(1559176630.387:30): avc: denied { write } for comm="audioserver"  path="pipe:[49495]" dev="pipefs" ino=49495 scontext=u:r:hal_audio_default:s0  tcontext=u:r:audioserver:s0 tclass=fifo_file permissive=1
提取：
scontext=u:r:hal_audio_default:s0
tcontext=u:r:audioserver:s0
tclass=fifo_file

更改： 在hal_audio_default.te 中
allow  hal_audio_default  audioserver:fifo_file write

转：https://www.jianshu.com/p/a3572eee341c

DAC和MAC的区别：

DAC核心思想：进程理论上所拥有的权限与执行它的用户的权限相同。比如，以root用户启动Browser，那么Browser就有root用户的权限，在Linux系统上能干任何事情。MAC核心思想：即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限，进程就没有该权限

DAC和MAC的联系：

Linux系统先做DAC检查，如果没有通过DAC权限检查，则操作直接失败。通过DAC检查之后，再做MAC权限检查。

SEAndroid简介

SELinux 全称 Security Enhanced Linux (安全强化 Linux)，是MAC (Mandatory Access Control，强制访问控制系统)的一个实现。其目的在于明确的指明某个进程可以访问哪些资源(文件、网络端口等)。Android系统基于Linux实现。针对传统Linux系统，NSA开发了一套安全机制SELinux，用来加强安全性。然而，由于Android系 统有着独特的用户空间运行时，因此SELinux不能完全适用于Android系统。为此，NSA同Google一起针对Android系统，在SELinux基础上开发了 SEAndroid。整体框架

图1 SEAndroid整体框架图如图1所示，SEAndroid安全机制包含有内核空间和用户空间两部分支持。 内核空间的selinux lsm module模块负责内核资源的安全访问控制。 sepolicy描述的是资源安全访问策略。系统在启动的时候，init进程会将内核空间安全访问策略加载内核空间的selinux lsm模块中去，而用户空间的安全访问策略则直接保存到普通文件中。 用户空间的SecurityServer一方面需要检索用户空间的安全策略，另一方面也需要检索内核空间的安全策略。 用户空间的libselinux库封装了对SELinux文件系统接口的读写操作。用户空间的SecurityServer访问内核空间的selinux lsm模块时，都是间接地通过libselinux进行的。用户空间的SecurityServer检索用户空间的安全策略时，同样也是通过 libselinux库来进行的。

安全策略

安全上下文

SEAndroid是一种基于安全策略的MAC 安全机制。这种安全策略又是建立在对象的安全上下文的基础上的。这里所说的对象分为两种类型，一种称 主体（Subject），一种称为客体（Object）。主体通常就是指进程，而客体就是指进程所要访问的资源，例如文件、系统属性等。安全上下文实际上就是一个附加在对象上的标签（label）。这个标签实际上就是一个字符串，它由四部分内容组成，分别是SELinux用户、SELinux 角色、类型、安全级别，每一个部分都通过一个冒号来分隔，格式为“user:role:type:rank”。

查看一个进程的安全上下文：

    root@ferrari:/ # ps -Z initLABEL 
  USER     PID   PPID  NAMEu:r:init:s0                  
   root      1     0      /init 

u为user的意思。SEAndroid中定义了一个SELinux用户，值为u。
r 为role的意思。role是角色之意，它是SELinux中一种比较高层次，更方便的权限管理思路，即 Role Based Access Control（基于角色的访问控制，简称为RBAC）。简单点说，一个u可以属于多个role，不同的role具 有不同的权限。

init代表该进程所属的domain类型为init。

s0和SELinux为了满足军用和教育行业而设计的Multi-Level Security（MLS）机制有关。简单点说，MLS将系统的进程和文件进行了分级，不同级别的资源需要对应级别的进程才能访问。

查看一个文件的安全上下文：

root@ferrari:/ # ls -Z sepolicy

-rw-r--r-- root    root              u:object_r:rootfs:s0 sepolicy

u：同样是user之意，它代表创建这个文件的SELinux user。

object_r：文件是被进程访问的，它没法扮演角色，所以在SELinux中，只能被进程访问的资源都用object_r来表示它的role。

rootfs：资源文件的Type，和进程的Domain其实是一个意思。它表示root目录对应的Type是rootfs。

s0：MLS的级别。

注意：
在安全上下文中，只有类型（Type）才是最重要的，SELinux用户、SELinux角色和安全级别都几乎可以忽略不计的。正因为如此，SEAndroid安全机制又称为是基于TE（Type Enforcement）策略的安全机制。

在SEAndroid中，只定义了一个SELinux用户u，因此我们通过ps -Z和ls -Z命令看到的所有的进程和文件的安全上下文中的SELinux用户都为u。同时，SEAndroid也只定义了一个SELinux角色r，因此，我们通 过ps -Z命令看到的所有进程的安全上下文中的SELinux角色都为r。

用户(user)和角色(role)：

安全级别(rank):

安全级别实际上也是一个MAC安全机制，它是建立在TE的基础之上的。在SELinux中，安全级别是可选的，也就是说，可以选择启用或者不启用。安全级别最开始的目的是用来对政府分类文件进行访问控制的。在基于安全级别的MAC安全机制中，主体（subject）和客体（object）都关联有一 个安全级别。其中，安全级别较高的主体可以读取安全级别较低的客体，而安全级别较低的主体可以写入安全级别较高的客体。前者称为“read down”，而后者称为“write up”。通过这种规则，可以允许数据从安全级别较低的主体流向安全级别较高的主体，而限制数据从安全级别较高的主体流向安全级别较低的主体，从而有效地保护了数据。注意: 如果主体和客体的安全级别是相同的，那么主体是可以对客体进行读和写的。在实际使用中，安全级别(rank)是由敏感性(Sensitivity)和类别(Category)两部分内容组成的，格式为 “sensitivity[ :category_set]”，其中，category_set是可选的。例如，假设我们定义有s0、s1两个 Sensitivity，以c0、c1、c2三个Category，那么“s0:c0,c1”表示的就是Sensitivity为s0、Category为c0和c1的一个安全级别。

类型(type):

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

路径:external/sepolicy/init.te

init switches to init domain (via init.rc).

type init, domain;

这样就可以表明init描述的类型是用来描述进程的安全上下文的。sepolicy文件类型定义：

路径：external/sepolicy/file_contexts

/sepolicy        u:object_r:rootfs:s0

路径：external/sepolicy/file.te

type rootfs, fs_type;

上述语句表明类型rootfs具有属性file_type，即它是用来描述文件的安全上下文的。

安全策略文件模块：

AOSP提供的所有Android策略文件都在路径external/sepolicy目录下面，在编译完成之后一共会生成如下个module:

sepolicy:

sepolicy 其主要用于配置进程的安全上下文用来控制进程访问内核资源(文件，端口等等)策略和设置虚拟文件系统的安全上下文，系统启动之后，会由init进程在 /sys/fs /selinux中安装一个selinux虚拟文件系统，接着再加载SEAndroid安全策略到内核空间的selinux lsm模块中去。其是由如下所示的所有te文件编译而成

路径：external/sepolicy/Android.mk

sepolicy_build_files := security_classes \initial_sids \access_vectors \global_macros \mls_macros \mls \policy_capabilities \te_macros \attributes \*.te \roles \users \initial_sid_contexts \fs_use \genfs_contexts \port_contexts

其中，genfs_contexts描述的是系统设置虚拟文件系统的安全上下文，例如

路径: external/sepolicy/genfs_contextfs

# proc labeling can be further refined (longest matching prefix).

genfscon proc / u:object_r:proc:s0

从这里可以看出将proc虚拟文件系统的安全上下文配置成u:object_r:proc:s0， 这以为这只有哪些允许访问type为proc的文件的进程才可以访问proc虚拟文件系统，也就是/proc目录下的文件

file_contexts:

file_contexts模块用于设置打包在ROM里面的文件的安全上下文。其是由external/sepolicy/file_contexts文件编译而成。例如在build systemimage时会将这个file_contexts文件路径传递给命令make_ext4fs时，就会根据它设置的规则给打包在 system.img里面的文件关联安全上下文。这样我们就获得了一个关联有安全上下文的system.img镜像文件了。这样通过fastboot命令将system.img刷入system分区mount到/system目录之后，因为设置了相应的安全上下文，这样就能控制进程访问system目录下相关文件.

property_contexts:

在Android系统中，有一种特殊的资源——属性，App通过读写它们能够获得相应的信息，以及控制系统的行为，因此，SEAndroid也需要对它们进行保护。这意味着Android系统的属性也需要关联有安全上下文。

路径：external/sepolicy/property_contexts
 property service keys
net.rmnet               u:object_r:net_radio_prop:s0
net.gprs                u:object_r:net_radio_prop:s0
net.ppp                 u:object_r:net_radio_prop:s0...

属性的安全上下文与文件的安全上下文是类似的，将属性net.rmnet设置为u:object_r:net_radio_prop:s0， 意味着只有有权限访问type为net_radio_prop的资源的进程才可以访问这个属性

service_contexts

在AndroidL系统中，还将服务(属于进程或线程)也作为一种资源来定义，给其定义对应的安全上下文，用来保护服务不被恶意进程访问.

...window                                    u:object_r:system_server_service:s0
*                                         u:object_r:default_android_service:s0

服务的安全上下文同样与文件的安全上下文是类似的，将window服务设置为u:object_r:system_server_service:s0，意味着只有有权限访问type为system_server_service的资源的进程才可以访问这个服务。