SELinux 即Security-Enhanced Linux，由美国国家安全局(NSA)发起，Secure Computing Corporation (SCC) 和 MITRE直接参与开发，以及很多研究机构(如犹他大学)一起参与的强制性安全审查机制，该系统最初是作为一款通用访问软件，发布于2000年12月(代码采用 GPL 许可发布)。并在Linux Kernel 2.6 版本后，有直接整合进入SELinux， 搭建在Linux Security Module(LSM)基础上，目前已经成为最受欢迎，使用最广泛的安全方案。而SEAndroid是Google在Android 4.4上正式推出的一套以SELinux为基础于核心的系统安全机制。

1、背景知识

2、SELinux and SEAndroid的发展

       Android是建立在标准的Linux Kernel基础上，自然也可以开启SELinux，通常在通用移动平台上，很少开启这样的安全服务，Google为了进一步增强Android的安全性，经过长期的准备，目前已经在Android 5.0(L)上有完整的开启SELinux，并对SELinux进行深入整合形成了SEAndroid。

      SELinux的更新史如下图所示：

                                                                                                                              图一：SELinux发展图

    

3、SElinux、SEAndroid基本架构与原理

     

         SELinux是典型的MAC实现，对系统中每个对象都生成一个安全上下文(Security Context), 每一个对象访问系统的资源都要进行安全上下文审查。审查的规则包括类型强制检测(type enforcement)，多层安全审查(Multi-LevelSecurity)，及基于角色的访问控制(RBAC: Role Based Access Control)。

SELinux的整体结构如下图所示:

     

图3：SELinux整体结构体

      

SELinux 包含五个基本组成：

     * 用于处理文件系统的辅助模块，即SELinuxFS。
     * 集成Linux Security Modules的hooks sets。
     * Security Policy Database。
     * Security Label验证模块。
     *  Access Vector Cache (AVC),访问向量缓存,以便提高验证速度。

基本的访问流程如下图所示：

图4：基本访问流程图

  具体 流程如下：
    * 进程通过系统调用(System Call)访问某个资源，进入Kernel后，先会做基本的检测，如果异常则直接返回。
    * Linux Kernel DAC审查,如果异常则直接返回.
    * 调用Linux Kernel Modules的相关hooks,对接到SELinux的hooks，进而进行MAC验证，如果异常则直接返回。
    * 访问真正的系统资源。
    * 返回用户态，将结构反馈。 

        SEAndroid安全机制是基于SELinux实现的，SEAndroid所要保护的对象是系统中的资源，这些资源分布在各个子系统中，例如我们经常接触的文件就是分布文件子系统中的。实际上，系统中需要保护的资源非常多，除了前面说的文件之外，还有进程、socket和IPC等等。对于Android系统来说，由于使用了与传统Linux系统不一样的用户空间运行时，即应用程序运行时框架，因此它在用户空间有一些特有的资源是需要特别保护的，例如系统属性的设置。

       SEAndroid安全机制也是分为内核空间跟用户空间两部分，以SELinux文件系统接口为边界。内核空间的实现是基于LSM实现的，上面主要是内核空间实现。而在用户空间，涉及到安全上下文（Security Context）、安全策略（SEAndroid Policy）和安全服务（Security Server）等模块。下面主要分析一下这三个模块。

      SELinux 给Linux 的所有对象都分配一个安全上下文(Security Context)， 描述成一个标准的字符串。这里的对象分为两种类型，Subject主体和Object访问对象。主体通常是以进程为单位，通常就是进程，而客体就是进程访问的资源，通常是以文件为单位。

       在开启了SEAndroid安全机制的设备上执行ls –Z就可以看到一个文件的上下文。

图5：文件SContext

  图5中最右边的那一列是文件的SContext，以结点touch的SContext为例，其值为u:object_r:touch_device:s0，其中：

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

     2、  object_r：文件是死的东西，它没法扮演角色，所以在SELinux中，死的东西都用object_r来表示它的role。

     3、  touch_device：死的东西的Type，和进程的Domain其实是一个意思。它表示root目录对应的Type是touch_device。

     4、  s0：MLS的级别。

     在来看看进程的SContext，同样在开启SEAndroid安全机制后，可以利用ps -Z来查看进程的上下文。

图6：进程SContext

图六中最左边的那一列是进程的SContext，以进程/system/bin/af7133d的SContext为例，其值为u:r:af7133d:s0，其中：

     1、u为user的意思。SEAndroid中定义了一个SELinux用户，值为u。

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

     3、af7133d，代表该进程所属的Domain为af7133d。MAC的基础管理思路其实不是针对上面的RBAC，而是所谓的Type Enforcement Accesc Control（简称TEAC，一般用TE表示）。对进程来说，Type就是Domain。比如init这个Domain有什么权限，都需要通过[例子1]中allow语句来说明。

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

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

     有时可能注意到，前面我们通过ps -Z命令看到进程init的安全上下文为“u:r:init:s0”，按照上面的分析，这是不是一个非法的安全上下文呢？答案是否定的，因为在另外一个文件external/sepolicy/init.te中，通过type语句声明了类型init，并且将domain设置为类型init的属性，如下所示：

type init, domain; 
   

   由于init具有属性domain，因此它就可以像domain一样，可以和SELinux用户u和SELinux角色组合在一起形成合法的安全上下文。

  SContext的标准格式如下所示：

user:role:type[:range] 

1、 User: 用户, 非Linux UID。

2、Role:  角色，一个user可以属于多个role，不同的role具有不同的权限。它是SELinux中一种比较高层次，更方便的权限管理思路，即Role BasedAccess Control（基于角色的访问控制，简称为RBAC, SELinux 不推荐使用）。

3、Type: Subject或者Object的类型。 MAC的基础管理思路其实不是针对上面的RBAC，而是所谓的Type Enforcement Access Control（简称TEAC，一般用TE表示）。对进程来说，Type就是Domain。

Range:Multi-Level Security（MLS）的级别。MLS将系统的进程和文件进行了分级，不同级别的资源需要对应级别的进程才能访问。

       上面我们分析了SEAndroid安全机制中的对象安全上下文，接下来我们就继续分析SEAndroid安全机制中的安全策略。SEAndroid安全机制中的安全策略是在安全上下文的基础上进行描述的，也就是说，它通过主体和客体的安全上下文，定义主体是否有权限访问客体。

        SEAndroid安全机制主要是使用对象安全上下文中的类型来定义安全策略，这种安全策略就称TypeEnforcement，简称TE。在external/sepolicy目录中，所有以.te为后缀的文件经过编译之后，就会生成一个sepolicy文件。这个sepolicy文件会打包在ROM中，并且保存在设备上的根目录下，即它在设备上的路径为/sepolicy。

      通常，TE的描述一般在device/mediatek/common/sepolicy/和external/sepolicy中，SEAndroid为系统定义了33个te策略文件，这33个策略文件是：

adbd.te、file.te、su.te、app.te、gpsd.te、netd.te、system.te、bluetoothd.te、init.te、net.te、ueventd.te、bluetooth.te、installd.te、nfc.te、unconfined.te、cts.te、kernel.te、qemud.te、vold.te、dbusd.te、keystore.te、radio.te、wpa_supplicant.te、debuggerd.te、mediaserver.te、rild.te、zygote.te、device.te、servicemanager.te、domain.te、shell.te、drmserver.te、surfaceflinger.te。

     对上述33个文件根据其策略规则针对的对象可分为三类：针对attribute的策略制定：ttribute是多个具有共性的type的集合，有unconfined.te、domain.te、CTS.te、bluetooth.te、net.te、file.te六个文件主要是直接针对attribute制定的策略，这种针对attribute制定的策略也就是同时对多个type制定策略一样。针对daemon domain的策略制定：分别为adbd.te、gpsd.te、netd.te、bluetoothd.te、zygote.te、ueventd.te、installd.te、vold.te、dbusd.te、keystore.te、debuggerd.te、mediaserver.te、rild.te、drmserver.te、surfaceflinger.te、qemud.te、servicemanager.te、su.te、shell.te、wpa_supplicant.te。这些文件都是为系统中的daemon进程进行策略的制定，它们都有着相应的daemon domain。最后的7个文件分别对系统的其他模块进行策略制定。app.te: 在这一文件里将安装在系统上的第三方app分类为受信任的app和不受信任的app，分别用不同的type表示，再分别为这两种app在访问网络，bluetooth，sdcard，数据，缓存，binder等等名感位置时设置相应权限。system.te: 这一文件主要针对的是系统app和system server进程。对系统app访问binder、systemdata files、dalvikcatch、keystone等进行权限控制，对system server访问网络、bluetooth、netlink、app、binder、device、data files、socket、cache files等进行权限控制。init.te: 在这一文件中声明了init拥有无限权限。nfc.te: 在这一文件中制定了nfc domain对nfc设备和相关数据文件的访问权限。kernel.te: 在这一文件中声明了kernel拥有无限权限。radio.te: 在这一文件中制定了radio domain对init、rild和相关数据文件的访问权限。device.te: 在这一文件中定义了所有跟设备相关的type，并将这些type都归到了dev_type属性中。

     而对于安全服务，用户空间的Security Server主要是用来保护用户空间资源的，以及用来操作内核空间对象的安全上下文的，它由应用程序安装服务PackageManagerService、应用程序安装守护进程installd、应用程序进程孵化器Zygote进程以及init进程组成。其中，PackageManagerService和installd负责创建App数据目录的安全上下文，Zygote进程负责创建App进程的安全上下文，而init进程负责控制系统属性的安全访问。

4、SELinux问题解决方法

      查找SELinux权限问题，一般的方法是通过查看LOG中是否有标准的SELinux Policy Exception。在Kernel Log / Main Log 中查询关键字"avc:"，如果出现以下log，则基本说明该问题就是SELinux权限问题引起的，在解决安全权限问题前，我们必须先读懂log中的信息：

[  215.214223]<0> (0)[307:logd.auditd]type=1400 audit(1420070451.950:8): avc: denied { write } for pid=4663 comm="om.zte.engineer" name="brightness" dev="sysfs" ino=9451 scontext=u:r:radio:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0
    

    * [  215.214223]：kernel time ；

    * [307:logd.auditd]：表示此LOG 是通过auditd 打印的；

    * type=1400  : SYSCALL ；如果type=AVC 表示为kernelevents， type=USER_AVC 表示user-space object manager events ；

    * audit(1420070451.950:8)：audit(time:serial_number)；

    * avc: denied { write }： field depend on what type of event is being audited.；

    * pid=4663 comm="om.zte.engineer"：如果是个进程，pid表示为进程号，comm为运行的进程名字；

    * scontext=u:r:radio:s0：subject context为u:r:radio:s0；

    * tcontext=u:object_r:sysfs:s0：target context 为u:object_r:sysfs:s0；

    * tclass : the object class of the target class=system；
    * permissive:  permissive (1)or enforcing (0)。

上面语句的大概意思为：om.zte.engineer这个process，使用radio的source context，访问sysfs这个文件类型时，并write文件时，被SELinux拒绝访问。

        而对于如何解决该类权限问题，一般的做法是，缺少什么就补什么，先介绍一下简化方法：

简化方法：

1、 提取所有的avc LOG.   如 adb shell "cat /proc/kmsg | grepavc" > avc_log.txt

2、  使用 audit2allow tool 直接生成policy. audit2allow -i avc_log.txt  即可自动输出生成的policy

3、  将对应的policy 添加到selinux policy 规则中，对应MTK Solution, 您可以将它们添加在KK: mediatek/custom/common/sepolicy, L:device/mediatek/common/sepolicy 下面，如
      allow zygoteresource_cache_data_file:dir rw_dir_perms;
      allow zygote resource_cache_data_file:filecreate_file_perms;
      ===>mediatek/custom/common/sepolicy/zygote.te (KK)
      ===> device/mediatek/common/sepolicy/zygote.te (L)

      这样做就可以达到允许zygote对resource_cache_data_file进行create、r/w操作。注意audit2allow它自动机械的帮您将LOG 转换成policy, 而无法知道你操作的真实意图，有可能出现权限放大问题，经常出现policy 无法编译通过的情况。

     如果直接按照avc: denied 的LOG 转换出SELinux Policy, 往往会产生权限放大问题. 比如因为要访问某个device, 在这个device 没有细化SELinux Label 的情况下, 可能出现:

 <7>[11281.586780] avc:  denied { read write } for pid=1217comm="mediaserver" name="tfa9897" dev="tmpfs"ino=4385 scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0tclass=chr_file permissive=0
     如果直接按照此LOG 转换出SELinuxPolicy:  allowmediaserver device:chr_file {read write};  那么就会放开mediaserver 读写所有device 的权限。而Google 为了防止这样的情况, 使用了neverallow 语句来约束, 这样你编译sepolicy 时就无法编译通过。

   下面主要介绍一下如何缺什么补什么，一步一步到没有avc: denied问题，以上面的avc log为例：

[  215.214223]<0> (0)[307:logd.auditd]type=1400 audit(1420070451.950:8): avc: denied { write } for pid=4663 comm="om.zte.engineer" name="brightness" dev="sysfs" ino=9451 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0
    

    分析过程：

     缺少什么权限：           { write}权限；

    谁缺少权限：                 scontext=u:r:radio:s0；

    对哪个文件缺少权限： tcontext=u:object_r:sysfs:s0

    什么类型的文件：        tclass=file

     所以解决方法是在：radio.te中加入

    allow radio sysfs:file write;

     通过上面例子，我们可以总结出一般规律：允许某个scontext对某个tcontext拥有某个权限。

    所以，可以得到一个万能套用公式：

       Scontext   tcontext   tclass  avc denied权限

allow        radio         sysfs  :   file      write

     有时候avc denied的log不是一次性显示所以问题，可能是要等你解决一个权限问题之后，才会提示另外一个权限问题，所以有时我们必须一次一次的试，一次一次的加。

      SEAndroid在te文件中定义了安全策略中最基本的参量type，同时将具有共性的type归在一起构成一个称为attribute的集合，policy的规则执行也能以attribute作为执行对象。SEAndroid为所有type共定义了17个attribute：

dev_type	这一attribute包含了所有关于设备的type
domain	这一attribute包含了如下所列的所有关于进程的type，通常策略中的访问主体也就是进程所在的domain都包含在了这一attribute中
fs_type	这一attribute包含了所有与文件系统相关的type。如下所列，大多是虚拟文件系统
file_type	这一attribute包含了所有存在于非伪文件系统的相关文件的type
exec_type	这一attribute包含了所有关于domian接入点的type，多被用在domain transition中
data_file_type	这一attribute包含了所有在/data目录下的文件type
sysfs_type	这一attribute包含了在sysfs文件系统下的所有文件的type，在SEAndroid中只有sysfs_writable包含在这个attribute中
node_type	这一attribute包含了所有与nodes/hosts有关的type，在SEAndroid中只有node包含在这个attribute中
netif_type	这一attribute包含了所有与网络接口相关的type，在SEAndroid中只有netif包含在这个attribute中
port_type	这一attribute包含了所有与网络端口相关的type，在SEAndroid中只有port包含在这个attribute中
mlstrustedsubject	这一attribute包含了所有能越过MLS检查的主体domain
unconfineddomain	这一attribute包含了所有拥有无限权限的type
appdomain	这一attribute包含了所有与app相关的type
netdomain	这一attribute包含了所有与需要访问网络的app相关的type
bluetoothdomain	这一attribute包含了所有与需要访问bluetooth的app相关的type
binderservicedomain	这一attribute包含了所有与binder服务相关的type

而在L 版本中，我们经常遇到下面几种访问对象通常与绑定的类：

1、 device  

类型定义	external/sepolicy/device.te device/mediatek/common/sepolicy/device.te
类型绑定	external/sepolicy/file_contexts device/mediatek/common/sepolicy/file_contexts

2、 File 类型:

类型定义	external/sepolicy/file.te device/mediatek/common/sepolicy/file.te
类型绑定	external/sepolicy/file_contexts device/mediatek/common/sepolicy/file_contexts

3、  虚拟File类型:

类型定义	external/sepolicy/file.te device/mediatek/common/sepolicy/file.te
类型绑定	external/sepolicy/genfs_contexts device/mediatek/common/sepolicy/genfs_contexts

4、  Service类型

类型定义	external/sepolicy/service.te device/mediatek/common/sepolicy/service.te
类型绑定	external/sepolicyservice_contexts device/mediatek/common/sepolicy/service_contexts

5、  Property类型

类型定义	external/sepolicy/property.te device/mediatek/common/sepolicy/property.te
类型绑定	external/sepolicy/property_contexts device/mediatek/common/sepolicy/property_contexts

  

前一篇文章已经介绍了SELinux相关知识，
https://blog.csdn.net/qq_33750826/article/details/80743035

基于 Android 4.3（宽容模式）和 Android 4.4（部分强制模式）的 Android 5.0 版本，开始全面强制执行 SELinux。

一、政策格式

政策规则采用以下形式：
allow domains types:classes permissions;
其中：

• Domain - 一个进程或一组进程的标签。也称为域类型，因为它只是指进程的类型。
• Type - 一个对象（例如，文件、套接字）或一组对象的标签。
• Class - 要访问的对象（例如，文件、套接字）的类型。
• Permission - 要执行的操作（例如，读取、写入）。

使用政策规则时将遵循的结构示例

allow appdomain app_data_file:file rw_file_perms;

这表示所有应用域都可以读取和写入带有 app_data_file 标签的文件。请注意，该规则依赖于在 global_macros 文件中定义的宏，您还可以在 te_macros 文件中找到一些其他非常实用的宏。这两个文件均位于 AOSP 源代码树的 system/sepolicy 目录中，其中提供了一些适用于常见的类、权限和规则分组的宏。应尽可能使用这些宏，以便降低因相关权限被拒而导致失败的可能性。

除了在规则中逐个列出域或类型之外，还可以通过属性引用一组域或类型。简单来说，属性是一组域或类型的名称。每个域或类型都可以与任意数量的属性相关联。当编写的规则指定了某个属性名称时，该名称会自动扩展为列出与该属性关联的所有域或类型。例如，domain 属性与所有进程域相关联，file_type 属性与所有文件类型相关联。

使用上述语法可以创建构成 SELinux 政策基本内容的 avc 规则。规则采用以下形式：

RULE_VARIANT SOURCE_TYPES TARGET_TYPES : CLASSES PERMISSIONS

该规则指明了，当带有任何 source_types 标签的主体尝试对某个对象执行与任何 permissions 对应的操作时，如果该对象包含带有任何 target_types 标签的任何 classes 类，会发生什么情况。这些规则的一个最常见示例是 allow 规则，例如：

allow domain null_device:chr_file { open };

该规则允许具有与“domain”属性关联的任何域的进程对 target_type 标签为“null_device”的“chr_file”类（字符设备文件）的对象执行“open”权限所描述的操作。在实际中，该规则可能会扩展为包含其他权限：

allow domain null_device:chr_file { getattr open read ioctl lock append write};

当了解到“domain”是分配给所有进程域的属性，并且 null_device 是字符设备 /dev/null 的标签时，该规则基本上会允许对 /dev/null 进行读写操作。

一个 domain 通常对应一个进程，而且具有与其关联的标签。

例如，典型的 Android 应用会在自己的进程中运行，并且具有 untrusted_app 标签（用于向其授予特定受限权限）。

系统中内置的平台应用会以单独的标签运行，并会被授予一组不同的权限。作为核心 Android 系统的一部分，系统 UID 应用以表示另一组权限的 system_app 标签运行。

在任何情况下，都不应直接允许域访问以下通用标签；而应为一个或多个对象创建一个更具体的类型：

• socket_device
• device
• block_device
• default_service
• system_data_file
• tmpfs

二、关键文件

• file_contexts - 位于 sepolicy子目录中。该文件用于为文件分配标签，并且可供多种用户空间组件使用。在创建新政策时，请创建或更新该文件，以便为文件分配新标签。要应用新的file_contexts，您必须重新构建文件系统映像，或对要重新添加标签的文件运行 restorecon。在升级时，对file_contexts所做的更改会在升级过程中自动应用于系统和用户数据分区。此外，还可以通过以下方式使这些更改在升级过程中自动应用于其他分区：在以允许读写的方式装载相应分区后，将restorecon_recursive 调用添加到 init.board.rc 文件中。

• genfs_contexts - 位于 sepolicy 子目录中。该文件用于为不支持扩展属性的文件系统（例如，proc 或vfat）分配标签。此配置会作为内核政策的一部分进行加载，但更改可能对核心内 inode无效。要全面应用更改，需要重新启动设备，或卸载后重新装载文件系统。此外，通过使用 context=mount选项，还可以为装载的特定系统文件（例如 vfat）分配特定标签。

• property_contexts - 位于 sepolicy 子目录中。该文件用于为 Android 系统属性分配标签，以便控制哪些进程可以设置这些属性。在启动期间，init 进程会读取此配置。

• service_contexts - 位于 sepolicy 子目录中。该文件用于为 Android Binder 服务分配标签，以便控制哪些进行可以为相应服务添加（注册）和查找（查询）Binder 引用。在启动期间，servicemanager 进程会读取此配置。
  seapp_contexts - 位于 sepolicy 子目录中。该文件用于为应用进程和 /data/data 目录分配标签。在每次应用启动时，zygote 进程都会读取此配置；在启动期间，installd 会读取此配置。

• mac_permissions.xml - 位于 sepolicy 子目录中。该文件用于根据应用签名和应用软件包名称（后者可选）为应用分配 seinfo 标记。然后，分配的 seinfo 标记可在 seapp_contexts 文件中用作密钥，以便为带有该 seinfo 标记的所有应用分配特定标签。在启动期间，system_server 会读取此配置。

三、政策示例

以下是一个完整的 DHCP 政策示例，我们将在下文中对其进行分析：

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

下面我们来分析一下该示例：

在第一行（即类型声明）中，该政策声明 DHCP 守护进程将沿用基本的安全政策 (domain)。从前面的声明示例中，我们知道 DHCP 可以从 /dev/null 读取数据以及向其写入数据。

在第二行中，DHCP 被声明为宽容域。

在 init_daemon_domain(dhcp) 这一行中，该政策声明 DHCP 是从 init 衍生而来的，并且可以与其进行通信。

在 net_domain(dhcp) 这一行中，该政策允许 DHCP 使用 net 域中的常用网络功能，例如读取和写入 TCP 数据包、通过套接字进行通信，以及执行 DNS 请求。

在 allow dhcp proc_net:file write; 这一行中，该政策声明 DHCP 可以向 /proc 中的特定文件写入数据。这一行显示了 SELinux 的详细文件标签。它使用 proc_net 标签来限定 DHCP 仅对 /proc/sys/net 中的文件具有写入权限。

该示例的最后一部分以 allow dhcp netd:fd use; 开头，描述了允许应用之间如何进行交互。该政策声明 DHCP 和 netd 之间可通过文件描述符、FIFO 文件、数据报套接字以及 UNIX 信息流套接字进行通信。DHCP 只能从数据报套接字和 UNIX 信息流套接字中读取数据以及向它们写入数据，但不能创建或打开此类套接字。

可用控件

neverallow 规则
SELinux neverallow 规则用于禁止在任何情况下都不应该发生的行为。通过执行兼容性测试，现在各种合作伙伴设备上都会强制执行 SELinux neverallow 规则。

以下准则旨在协助制造商在自定义过程中避免与 neverallow 规则相关的错误。此处使用的规则编号与 Android 5.1 中使用的编号一致，并且会因版本而异。

规则 48：

neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;

请参阅 ptrace 的帮助页面。sys_ptrace 功能用于授予对任何进程执行 ptrace 命令的权限。拥有该权限后，可以对其他进程进行广泛的控制。应该只有该规则中列出的指定系统组件享有该权限。如果需要该功能，则通常表明存在的某些内容不适用于面向用户的版本或存在不需要的功能。请移除不必要的组件。

规则 76：

neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;

该规则旨在防止执行系统中的任意代码。具体来说就是，该规则声明仅执行 /system 中的代码，以便通过验证启动等机制实现安全保证。通常，在遇到与这个 neverallow 规则相关的问题时，最好的解决办法是将违规代码移到 /system 分区。

四、读取拒绝事件

接下来是检查是否存在错误。错误会以事件日志的形式传给 dmesg 和 logcat，并可在设备上从本地查看。制造商应先检查这些设备上传给 dmesg 的 SELinux 输出并优化设置，然后再在宽容模式下公开发布，最后切换到强制模式。SELinux 日志消息中包含“avc:”字样，因此可使用 grep 轻松找到。您可以使用 cat /proc/kmsg 来获取当前的拒绝事件日志，也可以使用 cat /proc/last_kmsg 来获取上次启动时的拒绝事件日志。

根据这些输出内容，制造商可以轻松发现系统用户或组件违反 SELinux 政策的行为。然后，制造商便可更改相应软件和/或 SELinux 政策，以防范此类恶意行为。

具体来说，这些日志消息会指明在强制模式下哪些进程会失败以及失败原因。示例如下：

avc: denied  { connectto } for  pid=2671 comm="ping" path="/dev/socket/dnsproxyd"
scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket

该输出的解读如下：

• 上方的 { connectto } 表示执行的操作。根据它和末尾的 tclass(unix_stream_socket)，您可以大致了解是对什么对象执行什么操作。在此例中，是操作方正在试图连接到 UNIX
  信息流套接字。
• scontext (u:r:shell:s0) 表示发起相应操作的环境，在此例中是 shell 中运行的某个程序。
• tcontext (u:r:netd:s0) 表示操作目标的环境，在此例中是归 netd 所有的某个 unix_stream_socket。
• 顶部的 comm="ping" 可帮助您了解拒绝事件发生时正在运行的程序。在此示例中，给出的信息非常清晰明了。

下面是另一个示例：

adb shell su root dmesg | grep 'avc: '

输出：

<5> type=1400 audit: avc:  denied  { read write } for  pid=177
comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0
tcontext=u:object_r:kmem_device:s0 tclass=chr_file

以下是此拒绝事件的关键元素：

• 操作 - 试图进行的操作列在花括号中：read write 或 setenforce。
• 操作方 - scontext（来源环境）条目表示操作方；在此例中为 rmt_storage 守护进程。
• 对象 - tcontext（目标环境）条目表示是对哪个对象执行操作；在此例中为 kmem。
• 结果 - tclass（目标类别）条目表示操作对象的类型；在此例中为 chr_file（字符设备）。

使用 audit2allow

selinux/policycoreutils/audit2allow 工具可以获取 dmesg 拒绝事件并将其转换成相应的 SELinux 政策声明。因此，该工具有助于大幅加快 SELinux 开发速度。 audit2allow 包含在 Android 源代码树中，会在您基于源代码编译 Android 时自动编译。

要使用该工具，请运行以下命令：

adb pull /sys/fs/selinux/policy
adb logcat -b all -d | audit2allow -p policy

不过，请务必仔细审核要添加到政策中的条目，以免出现权限过宽的情况。例如，如果将上面的 rmt_storage 拒绝事件输入到 audit2allow 中，会生成以下 SELinux 政策声明建议：

#============= shell ==============
allow shell kernel:security setenforce;
#============= rmt ==============
allow rmt kmem_device:chr_file { read write };

这会授予 rmt 向内核内存写入内容的权限，从而形成明显的安全漏洞。通常情况下，audit2allow 给出的声明建议只是一个大致的基础。在添加这些声明后，您可能需要更改来源域和目标标签，并纳入适当的宏，才能实现良好的政策配置。有时，拒绝事件的合理应对方式不是对政策进行更改，而是更改违规的应用。

五、解决核心服务生成的拒绝事件

核心服务生成的拒绝事件通常是通过为文件添加标签来解决的。例如：

avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1

avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

是完全通过为 /dev/kgsl-3d0 添加适当的标签来解决的。在此示例中，tcontext 是 device。这表示默认环境，在该环境中，/dev 中的文件除非被分配了更具体的标签，否则都会获得“device”标签。直接在此处接受来自 audit2allow 的输出会导致不正确且过度宽容的规则。

/file_contexts

要解决这种问题，可以为文件添加更具体的标签，在此示例中为 gpu_device

/file_contexts

相应的政策，mediaservice.te

一般情况下，向默认标签授予权限的做法是错误的。其中许多权限都是 neverallow 规则所不允许的，但即使该规则并未明确禁止这些权限，也最好是提供具体标签。

常见错误

过度使用否定

以下示例规则类似于锁着前门，但开着窗户：

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

该规则的意图很明确：除了第三方应用之外，其他所有应用都可以访问调试设备。

该规则存在几个方面的缺陷。排除 untrusted_app 所起到的效果微不足道，因为所有应用都可以选择在 isolated_app 网域中运行服务。同样，如果第三方应用的新域被添加到了 AOSP，它们也可以访问 scary_debug_device。该规则过于宽容。对于大多数域来说，能够访问该调试工具并不能使它们获益。该规则应编写为仅允许需要访问该调试工具的域。

为新服务添加标签并解决拒绝事件

通过 init 启动的服务需要在各自的 SELinux 域中运行。以下示例会将服务“foo”放入它自己的 SELinux 域中并为其授予权限。

该服务是在设备的 init.<target>.rc 文件中启动的，如下所示：

service foo /system/bin/foo
    class core

1. 创建一个新域“foo”
   创建包含以下内容的文件 device/<oem>/<target>/sepolicy/foo.te：

# foo service
type foo, domain;
type foo_exec, exec_type, file_type;

init_daemon_domain(foo)

这是 foo SELinux 域的初始模板，您可以根据该可执行文件执行的具体操作为该模板添加规则。

2、 为 /system/bin/foo 添加标签
将以下内容添加到 device/<oem>/<target>/sepolicy/ file_contexts：

/system/bin/foo   u:object_r:foo_exec:s0

这可确保为该可执行文件添加适当的标签，以便 SELinux 在适当的域中运行相应服务。

3、编译并刷写启动映像和系统映像。

4、优化相应域的 SELinux 规则。

根据拒绝事件确定所需的权限。audit2allow 工具提供了一些实用的指南，但该工具仅适用于提供编写政策时所需的信息。切勿只是复制输出内容。

一.介绍

1.1百度百科

SELinux(Security-Enhanced Linux) 是美国国家安全局（NSA）对于强制访问控制的实现，是 Linux历史上最杰出的新安全子系统。NSA是在Linux社区的帮助下开发了一种访问控制体系，在这种访问控制体系的限制下，进程只能访问那些在他的任务中所需要文件。SELinux 默认安装在 Fedora 和 Red Hat Enterprise Linux 上，也可以作为其他发行版上容易安装的包得到。

SELinux 是 2.6 版本的 Linux 内核中提供的强制访问控制(MAC）系统。对于可用的 Linux安全模块来说，SELinux 是功能最全面，而且测试最充分的，它是在 20 年的 MAC 研究基础上建立的。SELinux 在类型强制服务器中合并了多级安全性或一种可选的多类策略，并采用了基于角色的访问控制概念。 [1]

大部分使用 SELinux 的人使用的都是 SELinux 就绪的发行版，例如 Fedora、Red Hat Enterprise Linux (RHEL）、Debian或 Centos。它们都是在内核中启用 SELinux 的，并且提供一个可定制的安全策略，还提供很多用户层的库和工具，它们都可以使用 SELinux 的功能。

SELinux是一种基于 域-类型 模型（domain-type）的强制访问控制（MAC）安全系统，它由NSA编写并设计成内核模块包含到内核中，相应的某些安全相关的应用也被打了SELinux的补丁，最后还有一个相应的安全策略。任何程序对其资源享有完全的控制权。假设某个程序打算把含有潜在重要信息的文件扔到/tmp目录下，那么在DAC情况下没人能阻止他。SELinux提供了比传统的UNIX权限更好的访问控制。

1.2概念

安全增强型 Linux（Security-Enhanced Linux）简称 SELinux，它是一个 Linux 内核模块，也是 Linux 的一个安全子系统。

SEAndroid是Google在Android 4.4上正式推出的一套以SELinux为基础于核心的系统安全机制。

SELinux 主要作用就是最大限度地减小系统中服务进程可访问的资源（最小权限原则）

1.3作用

SELinux 主要作用就是最大限度地减小系统中服务进程可访问的资源（最小权限原则）。

在没有使用 SELinux 的操作系统中，决定一个资源是否能被访问的因素是：某个资源是否拥有对应用户的权限（读、写、执行）。只要访问这个资源的进程符合以上的条件就可以被访问。进程理论上所拥有的权限与执行它的用户的权限相同。比如，以root用户启动Browser，那么Browser就有root用户的权限，在Linux系统上能干任何事情。root 用户不受任何管制，系统上任何资源都可以无限制地访问。

在使用了 SELinux 的操作系统中，决定一个资源是否能被访问的因素除了上述因素之外，还需要判断每一类进程是否拥有对某一类资源的访问权限。

这样一来，即使进程是以 root 身份运行的，也需要判断这个进程的类型以及允许访问的资源类型才能决定是否允许访问某个资源。进程的活动空间也可以被压缩到最小。

即使是以 root 身份运行的服务进程，一般也只能访问到它所需要的资源。即使程序出了漏洞，影响范围也只有在其允许访问的资源范围内，安全性大大增加。

二.SELinux Policy语言介绍

Linux中一切皆文件，而操作文件的为进程。：进程能发起动作，例如它能打开文件并操作它。而文件只能被进程操作。我们这里可以看做主体对客体进行某种动作。

1. 主体（Subject）

就是想要访问文件或目录资源的进程。想要得到资源，基本流程是这样的：由用户调用命令，由命令产生进程，由进程去访问文件或目录资源。在自主访问控制系统中（Linux 默认权限中），靠权限控制的主体是用户；而在强制访问控制系统中（SELinux 中），靠策略规则控制的主体则是进程。

可以完全等同于进程。ps:为方便理解，以下将进程视为主题

2. 对象（Object）

被主体访问的资源，也称为客体。可以是文件、目录、端口、设备等

ps:为方便理解，以下将目录活文件视为对象

3. 政策和规则（Policy & Rule）

Linux 系统中进程与文件的数量庞大，那么限制进程是否可以访问文件的 SELinux 规则数量就更加烦琐，如果每个规则都需要管理员手工设定，那么 SELinux 的可用性就会极低。还好我们不用手工定义规则，SELinux 默认定义了两个策略，规则都已经在这两个策略中写好了，默认只要调用策略就可以正常使用了。这两个默认策略如下：

• -targeted：这是 SELinux 的默认策略，这个策略主要是限制网络服务的，对本机系统的限制极少。我们使用这个策略已经足够了。
• -mls：多级安全保护策略，这个策略限制得更为严格。

系统中通常有大量的文件和进程，为了节省时间和开销，通常我们只是选择性地对某些进程进行管制，而哪些进程需要管制，要怎么管制是有政策决定的。

一套政策里面有多个规则，部分规则可以按照需求启用或禁用（以下吧该类型的规则成为布尔型规则）

规则是模块化，可扩展的。在安装新的应用程序时，应用程序可以通过添加新的模块来添加规则，用户也可以手动地增减规则

Xx域的进程(subject)是否可以对xx类的对象(object)进行xx操作   ===>Access decisions

给文件或者进程打上安全上下文标签 ===>Transition decisions

4.安全上下文（Security Context）

安全上下文是SELinux的核心，安全上下文即标签

安全上下文分为「进程安全上下文」和「文件安全上下文」

一个「进程安全上下文」一般对应多个「文件安全上下文」

进程安全上下文和文件安全上下文对应上，进程才能访问文件。它们的对应关系由政策中的规则决定。

文件安全上下文由文件创建的位置和创建文件的进程所决定，而且系统有一套默认值，用户也可以对默认值进行设定。

需要注意的是，单纯的移动文件操作并不会改变文件的安全上下文。

安全上下文有四个字段，分别用冒号隔开。形如：u:object_r:init_exec:s0

2.1SELinux工作模式

2.2TE介绍

RBAC是基于TE的，而TE也是SELinux中最主要的部分。 type 是访问决定的主要组成部分。

SELinux中安全策略文件有自己的一套语法格式：

rule_name source_type target_type : class perm_set 最常见的allow的语句，格式一般为：

allow   scontext tcontext:tclass    perm_set : 允许scontext域的进程对tcontext类型的tclass对象去执行perm_set操作

例如：allow netd proc:file write：允许netd域中的进程对proc类型的file进行写操作
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中所定义的操作。

Rule Name：

  rule_name一共有四种，定义如下：

  1）allow：赋予某项权限；

  2）allowaudit：audit含义就是记录某项操作，默认情况下SELinux只记录那些权限检查失败的操作。allowaudit则使得权限检查成功的操作也被记录。注意：allowaudit只是允许记录，它和赋予权限没有关系。赋予权限必须且只能使用allow语句。

  3）dontaudit：对那些权限检查失败的操作不做记录；

  4）neverallow：检查安全策略文件中是否有违反该项操作的allow语句；

Type

 在任何情况下，都不应直接允许域访问以下通用标签；而应为一个或多个对象创建一个更具体的类型：也就是需要自定义type，然后让type继承自这些类型，一个type可以关联多个attribute；

socket_device

device

block_device

default_service

system_data_file

tmpfs

….

SELinux是基于Domain-Type的强制类型访问模型，Domain其实也是Type，它只是对进程类型的习惯称呼；它只是对进程类型的习惯称呼，和Type相关的命令主要由三个：

 1）type：类型声明，可以直接在定义的时候，就赋予属性，type命令的完整格式为：

  type type_id [attribute_id][attribute_id] …;

其中方括号中的内容为可选项，attribute_id表示与type_id相关联的属性，一个type可以关联多个attribute；

例如下面定义了一个名为shell的type，它和一个名为domain的属性（attribute）关联：

  type shell, domain;// shell继承 domain，也就是说shell是一个进程

  type sysfs, fs_type, sysfs_type; //sysfs 继承fs_type, sysfs_type，也就是文件

2）attribute：属性，属性其实是一个特殊的type，可以把属性看成是type的集合，为属性设置的策略，适用于所有与该属性相关联的type，如下：

  attribute fs_type;                # 声明fs_type属性

  attribute sysfs_type;          # 声明sysfs_type属性

  # 允许init进程对sysfs_type类型集合的所有目录，文件执行relabelto操作

  allow init sysfs_type:{ dir file lnk_file } relabelto;

  注意：attributes文件中定义了SEAndroid中使用的所有属性；

3）typeattribute：单独给type赋予属性，在此之前需要先定义type类型，如下：

  Typeattribute system mlstrustedsubject;

 关键字           type      attibute

  特别注意：对于初学者而言，attribute和type的关系最难理解，因为”attribute”这个关键字实在没取好名字，很容易产生误解：

  a）实际上，type和attribute位于同一个命名空间，即不能用type命令和attribute命令定义相同名字的东西；

  b）其实，attribute真正的意思应该是类似typegroup这样的概念。比如将type A和attributeB关联起来，就是说type A属于attributeB中的一员；

  Object Class

  ObjectClass声明了进程要操作的对象类，security_classes文件定义了SEAndroid中用到的所有class；

  class关键字用于声明objectclass类型：

  # file-related classes

  class file            # 文件

  class dir            # 目录

  class fd             # 文件描述符

  class lnk_file     # 链接文件

  class chr_file    # 字符设备文件

  class blk_file     # 块设备文件

  … …

  # network-related classes

  class socket

  class tcp_socket

  class udp_socket

…..

Perm Set

  perm_set指的是某种ObjectClass所拥有的操作，以file类而言，就包括open,read, write等操作；和Object Class一样，SEAndroid所支持的permset的声明在access_vectors文件中；

  SELinux规范中，定义permset有两种方式：

  1）common：其命令的格式为：

  commoncommon_name { permission_name … }

  以下是file类对应的权限（permset），大部分各位都能猜出来是干什么的： 

  common file {

    ioctl read write create getattr setattr lock relabelfrom relabelto

    append unlink link rename execute swapon quotaon mounton }

  2）class：除了common外，还有一种class命令也可以设置permset，class命令可以继承common定义的permset；

  class命令的完整格式为：

  class class_name [inherits common_name] {permission_name … }

  inherits表示继承某个common定义的权限，如下：

  class dir inherits file {

    add_name remove_name reparent search rmdir open audit_access

    execmod }

三.常用命令

SELinux是经过安全强化的Linux操作系统，一些原有的命令都进行了扩展，另外还增加了一些新的命令，下面让我们看看经常用到的几个命令：

1）ls -Z命令查看文件，目录的安全属性：

root@xxx:/ # ls –Z

drwxr-x--x  root     sdcard_r   u:object_r:rootfs:s0 storage

dr-xr-xr-x    root     root            u:object_r:sysfs:s0 sys

drwxr-xr-x  root     root             u:object_r:system_file:s0 system

… …

2）ps -Z命令查看进程的安全属性：

root@xxx:/ # ls -Z

u:r:rild:s0                      radio       272   1     /system/bin/rild

u:r:drmserver:s0        drm          273   1     /system/bin/drmserver

u:r:mediaserver:s0  这个还是  media      274   1     /system/bin/mediaserver

u:r:installd:s0              install      283   1     /system/bin/installd

3）chcon命令更改文件的安全属性

A101LV:/mnt # ls -Z 1.txt                                                                                                                                                                  

u:object_r:appdomain_tmpfs:s0 1.txt

chcon u:object_r:storage_file:s0 1.txt

A101LV:/mnt # ls -Z 1.txt                                                                                                                                                                  

u:object_r:storage_file:s0 1.txt

4）restorecon命令当文件的安全属性在安全策略配置文件里面有定义时，使用restorecon命令，可以恢复原来的安全属性

restorecon 1.txt                                                                                                                                                         

SELinux: Loaded file_contexts

5）id命令使用id命令，能确认自己的SecurityContext

A101LV:/mnt # id

uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:su:s0

6）getenforce命令得到当前SELinux的模式值

A101LV:/mnt # getenforce

Enforcing

7）setenforce命令更改当前的SELINUX的模式值，后面可以跟 enforcing,permissive 或者1,0。

安全增强型 Linux (SELinux) 是适用于 Linux 操作系统的强制访问控制 (MAC) 系统

A101LV:/mnt # setenforce 0

A101LV:/mnt # getenforce                                                                                                                                                                   

Permissive

A101LV:/mnt # setenforce 1                                                                                                                                                                 

A101LV:/mnt # getenforce                                                                                                                                                                   

Enforcing

Enforcing：seLinux已经打开；         

Permissive：seLinux已经关闭；

8）查看selinux权限问题

adb shell dmesg -c |grep avc

audit: type=1400 audit(16149.949:4): avc:  denied  { write } for  pid=399 comm="init" name="vendor" dev="tmpfs" ino=988 scontext=u:r:vendor_init:s0 tcontext=u:object_r:tmpfs:s0 tclass=dir permissive=0

四.添加权限

了解selinux基本概念后，这里简单介绍一些权限的添加方法。

进程类型定义，vendor_init.te文件中：

type vendor_init, domain, mlstrustedsubject;

给新建对象打上label

如在file.te里面添加：

type tmpfs, fs_type;

….

例如：

audit: type=1400 audit(16149.949:4): avc:  denied  { write } for  pid=399 comm="init" name="vendor" dev="tmpfs" ino=988 scontext=u:r:vendor_init:s0 tcontext=u:object_r:tmpfs:s0 tclass=dir permissive=0

可以解读为scontext=u:r:vendor_init:s0 的主体(进程)对tcontext=u:object_r:tmpfs:s0的tclass=dir对象缺少{ write } 权限。

为了解决这个权限问题，我们添加vendor_init.te文件,内容为：

allow vendor_init tmpfs:dir { write };

注意，解决了这个问题后，可能会引入新的权限问题，我们再根据新的avc去添加。

五.快速验证

修改之后，怎么快速验证？

mmm system/sepolicy    && make sepolicy

生成out目录下，注意有两个目录：

system/etc/sepolicy---Android 原生的，建议不动。如果修改，会影响CTS

vendor/etc/sepolicy---第三方厂家修改。

特别说明：

system/sepolicy/Android.mk中定义了一些属性

BOARD_SEPOLICY_DIRS  ##此宏涉及到的目录，会编译到vendor/etc/sepolicy下

PLAT_PUBLIC_POLICY ##此宏涉及到的目录，会当成system/sepolicy/public

PLAT_PRIVATE_POLICY##此宏涉及到的目录，会当成system/sepolicy/private

另外，单独编译后，会发现都会有对应的生成目录：out/target/product/xxx/vendor/etc/selinux/

Allow语句会在vendor_sepolicy.cil文件中，最后push到板子/vendor/etc/selinux下

六.万能公式

audit(1599450077.672:2048): avc: denied { open } for comm=".android.camera" path="/dev/__properties__/u:object_r:vendor_default_prop:s0" dev="tmpfs" ino=297 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:vendor_default_prop:s0 tclass=file permissive=0 app=com.android.camera

某个scontext对某个tclass类型的tcontext缺乏某个权限，我们需要允许这个权限：

我们的log重新排列一下，

scontext = u:r:platform_app

tcontex t= u:object_r:vendor_default_pro:s0

tclass = file

avc: denied {  open  }

得到万能套用公式如下：

在scontext所指的.te文件（例如platform_app.te）中加入类似如下allowe内容：

allow  platform_app  vendor_default_pro:file  open;

七.其它

1. 有时候avc denied的log不是一次性暴露所有权限问题，要等解决一个权限问题之后，才会暴露另外一个权限问题。比如提示缺少某个目录的read权限，加入read之后，才显示缺少write权限，要一次次一次试，一次一次加，时间成本极大。
针对dir缺少的任何权限，建议赋予create_dir_perms，基本涵盖对dir的所有权限，比如：
{ open search write read rename create rmdir getattr }等等。
针对file缺少的任何权限，建议赋予rwx_file_perms，基本涵盖对file的所有权限，比如：
包含{ open read write open execute getattr create ioctl }等等。

更多内容请参考external/sepolicy/global_macros来了解更多权限声明。

2. 要加入的权限很多时，可以用中括号，比如：
allow engsetmacaddr  vfat:dir { search write add_name create};

3. 修改A位置的.te文件遇到编译错误怎么办？
（首先请排除拼写错误）说明此项权限是SELinux明确禁止的，也是Google CTS禁止的，如果产品不需要过CTS，可以修改。一般来说，编译出错的log会提示相关哪个文件哪一行出错，文件位置一定会在B里的.te文件。比如B规定了以下neverallow,
neverallow system_server sdcard_type:dir { open read write };
那么system_server是不能拥有这些权限的，如果赋予这些权限就编译报错，解决方法是根据编译错误提示的行号，把这一句注释掉即可。

4. ubuntu下面自动转换avc语句为selinux语句

 grep -r avc  sdcard.log  > avc.log ;   audit2allow  -i   avc.log

5. genfscon的语法是：
genfscon fs_type pathprefix [-file_type] context
把/proc/mtk_demo/demo_file文件的安全上下文设置成demo_context
genfscon proc /mtk_demo/demo_file u:object_r:demo_context:s0

6.内核模块

最终SELinux的实现是依赖于Linux提供的Linux Security Module框架简称为LSM。其实LSM的名字并不是特别准确，因为他并不是Linux模块，而是一些列的hook，同样也不提供任何的安全机制。LSM的的重要目标是提供对linux接入控制模块的支持。

Linux Security Module Framework

LSM 在内核数据结构中增加了安全字段，并且在重要的内核代码（系统调用）中增加了hook。可以在hook中注册回调函数对安全字段进行管理，以及执行接入控制。

                                                  AVC架构图

                                           完整的selinux架构图 

八.Selinux快速验证的方法

1：编译sepolicy模块

mmm system/sepolicy/

2：push selinux相关文件
adb push xxx/vendor/etc/selinux /vendor/etc/
adb push xxx/odm/etc/selinux /odm/etc/
adb push xxx/system/etc/selinux /system/etc/

3：重启样机即可验证