精华内容
下载资源
问答
  • Android8.0 SELinux详解
    千次阅读
    2019-01-05 16:04:46

    该文档意译自Android官方 《SELinux for Android 8.0》,主要描述了SELinux策略在AndroidO版本上发生的一些变化,在AndroidO版本上,SELinux的客制化设计支持SELinux策略的模块化和可更新性。其设计目标是为了芯片厂商和ODM厂商在能够独立的客制化SELinux配置。
    官方文档请移步:http://download.csdn.net/download/huangyabin001/10241242


    Android8.0 AndroidSELinux设计目标
    Android4.4到Android7.0,SELinux策略的构建流程是将所有的策略(平台和非平台)合并在一起,最后将合并生成的文件统一放在root目录下(即boot.img)。但这种方式有悖于Android 8.0的预定设计目标;Android8.0设计的初衷是允许合作方可以独立的更新他们自有的策略,即在Android8.0之后Google允许合作方将自有的策略部分与系统原有的进行分离,如合作方可以将自有的部分解耦到vendor.img分区中,在需要更新的情况下只需更新vendor部分即可实现;

    SELinux在Android8.0上的设计目标包含以下:
    策略模块化。在Android4.4到Android7.0,大部分SELinux策略文件都打包在根文件系统中,这样的话,策略文件改变的情况下,芯片厂商和ODM厂商需要同时更新boot.img和system.img(system.img只针对ab系统,因为ab系统的话,boot.img是打包在system.img镜像中的)。Android8.0之后,Google为SoC和ODM提供了新的方式,这种方式在他们自有的SELinux策略发生变化时仅需要修改他们自有的分区即可,如vendor.img;
    策略兼容性。

    关于Android8.0架构如下图:

    图1.Android分区
    system.img 包含Android 框架部分;
    boot.img 包含kernel和ramdisk;
    vendor.img 包含芯片厂商客制化代码和配置
    odm.img 包含dom厂商客制化代码和配置
    oem.img 包含oem厂商客制化部分代码和配置;
    bootloader 引导部分
    radio modem部分

    在Androird8.0之前,vendor、odm和omd镜像都是可选的;在这些镜像中的配置都是通过symlinks被放在boot.img和system.img中的(如/vendor>/system/vendor)。在Android8.0之后,vendor镜像被强制以镜像的形式分离出来了。

    这种模化设计体现在Android分区定义上,它使得平台在升级时(system.img)不会对SoC和ODM厂商自有部分的代码和配置产生影响。

    关于SELinux

    SELinux是通过标签系统来控制主体对客体的读写等访问权限的。每个进程或者其他主体都有一个相关联的标签;我们称之为安全上下文。这个上下文是有user,role,type,MLS四部分组成;
    type我们也称之为domain(域),这个域必须要在SELinux策略中进行定义;
    一个主体的标签常常由对应的安全上下文文件所决定;
    SELinux策略也包含角色,一个角色声明了哪些域可以访问哪些客体;在Andoird4.4到Android7.0的版本中,SELinxu策略文件(sepolicy,file_context.bin,property_context等)都是打包在根文件系统中的,如下:

    这些文件包含了SELinxu策略规则和所有的标签,包括ODM,SOC和AOSP。但是在Android8.0,这些文件将以模块的形式存在在不同的分区中;

    Android7.x的SELinux架构

    a.SELinux源文件
    SELinux源文件目录结构如下:
    external/selinux 外部SELinux工程
    external/selinux/libselinux
    external/selinux/libsepol
    chkcon
    libsepol 
    external/selinux/checkpolicy

    system/sepolicy Android SELinux策略核心配置,包含contexts和策略文件

    b.SELinux编译流程
    SELinux策略的创建实际上就是将AOSP 策略文件和设备制造商自定义的策略文件合并到一起,然后通过策略编译器编译,再通过各种策略校验机制校验,最终生成的一些如root/file_contexts.bin的文件,被打包到镜像中去。
    设备制造商可以通过在Boardconfig.mk文件,使用BOARD_SEPOLICY_DIRS宏定义,将自有客制化部分的策略文件包含进去。如:
    BOARD_SEPOLICY_DIRS += device/$SoC/common/sepolicy
    BOARD_SEPOLICY_DIRS += device/$SoC/$DEVICE/sepolicy

    system/sepolicy目录下的file_contexts和BOARD_SEPOLICY_DIRS定义的策略目录最终会编译生成file_contexts.bin文件。

    图2.SELinux 编译流程


    sepolicy策略文件是有多种源文件组成的,如:

    图3.SELinux策略文件
    policy.conf是由security_classes,initial_side,...*.te,genfs_contexts和port_contexts串联生成的。

    c.SELinux文件

    Android设备通常包含下面这些SELinux相关的文件
    selinux_version
    sepolicy : binary output after combining policy files ( security_classes ,
    initial_sids , *. te , etc.)
    file_contexts
    property_contexts
    seapp_contexts
    service_contexts
    system/etc/mac_permissions.xml

    d.SELinux初始化
    当系统启动时,SELinux并不是强制模式(enforcing mode),而是宽容模式(permissive mode)。init进程会执行以下操作:
    通过/sys/fs/selinux,从ramdisk中载入selinux策略文件到kernel中;
    切换SELinux到强制模式
    re-exec(),将SELinux域规则运用自己身上,即init进程。

    Android 8.0 SELinux设计思路
    a.第一阶段 mount
        在Android8.0之前,SELinux文件是通过合并自定义策略和aosp的策略。在Android8.0之后,Android提供了一种方式可以将非平台的策略从aosp平台中分离出,这样合作方就可以独立的对自有部分的SELinux策略进行构建和更新。
        解耦之后的SELinux策略文件可以存储在合作方自有的分区中(如vendor),这样一来,init进程需要更早的将system、vendor分区挂在起来,这样才能保证在init初始化的时候可以尽早的读取加载SELinux文件,并与保存在system目录下的核心SELinux文件合并起来,之后再将合并之后的SELinux策略加载到内核中去。

    b.SELinux上下文标签
    1>文件上下文
    Android8.0对file_contexts引入了以下修改:
    file_contexts以二进制的形式打包在镜像中,这在Android7.0以及之前的版本都是以可读的文本的形式存在的。
    Android8.0将file_contexts分离成了两个文件:
    Plat_file_contexts:Android平台file_context除了对vendor分区进行标记之外,没有其他有关设备制造商自有的标签了。平台相关的file_context必须打包到system分区,如/system/etc/selinux/plat_file_context。说白了也就是从Android8.0开始,SELinux平台相关的策略文件将会打包到system分区,这个要与Android7.0进行区分,详细如下:

    Android7.0图1

    Android8.0 图1

    Android8.0 图2
    注!上面目录在Andrid8.0平台上的boot分区中etc目录会对system/etc目录进行映射,如下:

    Android8.0 图3

    Nonplat_file_contexts:设备制造商的file_context必须打包在vendor分区,如/vendor/etc/selinux/nonplat_file_contexts。将会在设备启动时与plat_file_contexts一起合并,并被加载到kernel中。详细如下:

    Android8.0 图4


    Android8.0 图5

    2>属性上下文
    同文件上下文

    3>服务上下文
    同文件上下文

    4>seapp上下文
    同文件上下文

    5>mac权限
    同文件上下文

    c.主体或客体标签

        Android8.0 可以独立更新平台(system/boot分区)和设备制造商组件(vendor分区),意味着需要清楚的定义每一个客体的标签。举个例子,如果设备制造商组件(vendor分区)下有/dev/foo,平台组件也有/dev/foo,我们需要分别为不同的客体定义标签、属性、类型等其他内容;
    例如:
    1.针对platform和non-platform分别定义type或attribute
    type foo, domain; → type np_foo, domain;

    2.针对属性和进程分别不同的属性或其他内容;
    foo.xxx → np.foo.xxx
    ro.foo.xxx → ro.np.foo.xxx
    persist.foo.xxx → persist.np.foo.xxx

    3.针对文件分别定义不同的标签
    由于平台(aosp)和非平台(vendor或device-specific)策略都可以为整个文件系统提供标签声明,因此我们要通过一些规则来解决SELinux冲突;这里Android8.0给我们提供了一些很好的建议;

    >System(/system)
    system镜像下的文件只允许通过system/sepolicy中的file_contexts、service_contexts进行定义;也就是说,nonplat_file_contexts 不可以对system镜像中的对象进行标记。

    >Vendor(/vendor)

    官方文档还列举了/data,/dev等,这里不再赘述,可以查看源码了解;

    d.SELinux 策略构建和客制化
        在Android8.0中,SELinux策略分离成平台(platform)和非平台(non-platform)两部分,而平台策略为了给非平台作者导出特定的类型和属性,又分为平台私有(platform private)和平台公有(platform public)部分。

    1.平台公有策略(platform public seoplicy)
    平台共有策略全部定义在/system/sepolicy/public下,public下的type和attribute可以被non-platform中的策略所使用,也就是说,设备制造商的sepolicy作者在non-platform下可以对platform public sepolicy的策略进行扩展。

    2.平台私有策略(platform private seoplicy)
    与公有策略相反,被声明为私有策略的type或attribute对non-platform的策略作者是不可见的,这里有些费解,我们举例来说,这里以8.0版本的aosp源代码中的/system/sepolicy/private/目录下的atrace.te文件为例;
    8.0版本的aosp中的/system/sepolicy/private/file_contexts定义了“/system/bin/atrace    u:object_r:atrace_exec:s0”
    然后在/system/sepolicy/private/atrace.te中定义atrace相关的规则;
    我们在device/qcom/sepolicy/common目录下新增一个atrace.te文件,并添加规则 "allow atrace sdcardfs:file read;"
    当我们make进行编译时会在校验的时候失败,提示我们“device/qcom/sepolicy/common/atrace.te:2:ERROR 'unknown type atrace' at token ';' on line 23355”,那么也就是说private策略中的type和attribute对我们是不可见的。

    3.平台私有映射
    映射主要针对旧版本的映射,应用比较少,这里不作研究;


    e.构建SELinux策略

    Android8.0的SElinux策略是由/system和/vendor中的策略合并而来的。具体构建的逻辑声明在/platform/system/sepolicy/Android.mk中。
    Location    Contains
    system/sepolicy/public    平台策略
    system/sepolicy/private    平台策略
    system/sepolicy/vendor    平台对vendor相关的定义
    BOARD_SEPOLICY_DIRS    vendor 策略
    平台编译系统采用这种逻辑将平台和非平台策略组件分别打包在system镜像和vendor镜像中去。


    f.策略兼容性
    Android8.0 SELinux的模块化设计鼓励供应商(vendor)将自有部分的selinux与system部分分离开来,从而使得平台ota时具备更好的兼容性,比如新版本的SELinux配置与旧版本的SELinux配置的差异等。
    SELinux 策略是特定类型的对象(如file,dir,进程等),源域(主体)与目标域(客体)的交互;每个对象都受SELinux策略影响,每个对象至少要有一个type(类型),但这个类型(type)可以具备多个属性(attribute);

    g.平台更新
    下面列举了一些平台更新可能会遇到的场景:
    1.相同类型
    这种场景常常发生在selinux版本中没有对对象修改标签,怎么理解呢,当我们同时有很多个版本的SELinux时,而且多个版本均对"/dev/binder"进行type的定义。那就会发生冲突,解决冲突的办法就是在不同版本的SELinux,对type定义上添加版本后缀,如下:binder_device_v1 … binder_device_vN

    2.新类型
    这种场景常常发生在我们需要添加一个新功能时,需要添加一个新type时,平台已经添加了一个新类型(type)。

    3.删除type

    4.新类别和权限

    5.删除类别和权限
    --------------------- 
    作者:叶桐 
    来源:CSDN 
    原文:https://blog.csdn.net/huangyabin001/article/details/79290382 
    版权声明:本文为博主原创文章,转载请附上博文链接!

    更多相关内容
  • Android 5.0以后完全引入了 SEAndroid/SELinux 安全机制,这样即使拥有 root 权限或 chmod 777 ,仍然无法再JNI以上访问内核节点。 其实在 Android 4.4 就有限制的启用此安全机制了。后面内容都按照 5.0 以后介绍,...
  • SELinux详解-中文版.pdf

    2021-10-18 12:23:19
    讲解selinux的作用,生效机制,并详细介绍了如何编写selinux策略模块 中文版
  • Android有关selinux详解

    千次阅读 2019-11-26 10:46:08
    SELinux 即Security-Enhanced Linux,由美国国家安全局(NSA)发起,Secure Computing Corporation (SCC) 和 MITRE直接参与开发,以及很多研究机构(如犹他大学)一起参与的强制性安全审查机制,该系统最初是作为一款...

             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、背景知识

             SELinux出现之前,Linux上的安全模型叫DAC,全称是Discretionary Access Control,自主访问控制。自主访问控制, 即系统只提供基本的验证, 完整的访问控制由开发者自己控制。Linux DAC采用了一种非常简单的策略, 将资源访问者分成三类, 分别是Owner, Group,Other;资源针对这三类访问者设置不同的访问权限。而访问权限又分成read、 write、 execute。访问者通常是进程有自己的uid/gid, 通过uid/gid和文件权限匹配, 来确定是否可以访问。将Root权限根据不同的应用场景划分成许多的Root Capabilities, 其中如果有CAP_DAC_OVERRIDE这项的话, 可以直接绕过Linux DAC限制。DAC的核心思想很简单,就是:

           进程理论上所拥有的权限与执行它的用户的权限相同。比如,以root用户启动Browser,那么Browser就有root用户的权限,在Linux系统上能干任何事情。也就是像4.4以前的版本,只要我们对结点给予足够的权限,就可以随意的进行任意的操作。

           Linux DAC有明显的不足,其中一个重要点就是,Root权限“无法无天”,几乎可以做任意事情,一旦入侵者拿到root权限,即已经完全掌控了系统。另外每一个进程默认都拿到对应这个用户的所有权限,可以改动/删除这个用户的所有文件资源,明显这个难以防止恶意软件。所以在DAC之外设计了一个新的安全模型,叫MAC(Mandatory Access control),强制性访问控制,即系统针对每一项访问都进行严格的限制,具体的限制策略由开发者给出。MAC的处世哲学非常简单:即任何进程想在SELinux系统中干任何事情,都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限,进程就没有该权限。

          LinuxMAC针对DAC的不足,要求系统对每一项访问,每访问一个文件资源都需要进行针对性的验证。而这个针对性的验证是根据已经定义好了的策略进行。在Linux Kernel,所有的MAC机制都是搭建在Linux Security Modules(LSM)基础上,包括有:SELinux、Apparmor、Smack 和TOMOYOLinux等。目前SELinux已经成了事实上的行业标准。
           针对Linux DAC,MAC可以明显弥补DAC的缺陷,一方面限制Root权限,即使你有root权限,如果无法通过MAC验证,那么一样的无法真正执行相关的操作。另外对每一项权限进行了更加完整的细化,可限制用户对资源的访问行为。
          我们知道android是基于linux实现的,NSA为了linux的安全性开发了一套安全机制SElinux,但由于Android系统有着独特的用户空间,因此SELinux不能完全适用于Android系统。为此,NSA针对Android系统,在SElinux基础上开发了SEAndroid。 
         SEAndroid安全机制所要保护的对象是系统中的资源,这些资源分布在各个子系统中,例如我们经常接触的文件就是分布文件子系统中的。实际上,系统中需要保护的资源非常多,除了前面说的文件之外,还有进程、socket和IPC等等。对于Android系统来说,由于使用了与传统Linux系统不一样的用户空间运行时,即应用程序运行时框架,因此它在用户空间有一些特有的资源是需要特别保护的,例如系统属性的设置等等。

    2、SELinux and SEAndroid的发展

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

                                                                                                                                  图一:SELinux发展图
            上图中有Permissive跟Enforce两种模式,Permissive 模式,只打印audit 异常LOG,不拒绝请求, Enforce 模式,即打印audit 异常LOG, 也拒绝请求。AndroidKK版本只对netd、installd、zygote、vold四个原本具有root权限的process,以及它们fork出的子进程启用Enforce模式。但到了L 5.0以上版本普遍性开启SELinux Enforce mode。
        
                                                                                                                        图2:Android 启动模式变化
        

    估计在后续版本中,Google 都会要求强制性开启SELinux,以保证手机的安全。

    SELinux 给Android 带来下面影响:

             * 严格限制了ROOT 权限,以往ROOT “无法无天” 的情况将得到极大的改善。
             * 通过SELinux 保护,降低系统关键进程受攻击的风险,普通进程将没有权限直接连接到系统关键进程。
             * 进一步强化APP 的沙箱机制,确保APP 难以做出异常行为或者攻击行为。
             * 将改变APP 一旦安装,权限就已经顶死的历史,APP权限动态调整将成为可能。

    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中文.pdf

    2019-08-20 22:35:45
    详细介绍selinux 语法规则,作为开发手册,随时查看,挺使用的。
  • 中文selinux手册和selinux详细解说,非常适合入门学习,很受用。
  • Android进阶-SELinux

    2018-06-28 11:44:28
    前一篇文章已经介绍了SELinux相关知识... 基于 Android 4.3(宽容模式)和 Android 4.4(部分强制模式)的 Android 5.0 版本,开始全面强制执行 SELinux。 一、政策格式 政策规则采用以下形式: allow domain...

    前一篇文章已经介绍了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 子目录中。该文件用于为不支持扩展属性的文件系统(例如,procvfat)分配标签。此配置会作为内核政策的一部分进行加载,但更改可能对核心内 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 分区。

    四、读取拒绝事件

    接下来是检查是否存在错误。错误会以事件日志的形式传给 dmesglogcat,并可在设备上从本地查看。制造商应先检查这些设备上传给 dmesgSELinux 输出并优化设置,然后再在宽容模式下公开发布,最后切换到强制模式。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 writesetenforce
    • 操作方 - 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 添加适当的标签来解决的。在此示例中,tcontextdevice。这表示默认环境,在该环境中,/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 工具提供了一些实用的指南,但该工具仅适用于提供编写政策时所需的信息。切勿只是复制输出内容。

    展开全文
  • Selinux详解

    千次阅读 2021-10-21 10:34:44
    SELinux(Security-Enhanced Linux) 是美国国家安全局(NSA)对于强制访问控制的实现,是 Linux历史上最杰出的新安全子系统。NSA是在Linux社区的帮助下开发了一种访问控制体系,在这种访问控制体系的限制下,进程只能...

    一.介绍

    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概念

    安全增强型 LinuxSecurity-Enhanced Linux)简称 SELinux,它是一个 Linux 内核模块,也是 Linux 的一个安全子系统

    SEAndroidGoogleAndroid 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

    •u为user的意思。SEAndroid中定义了一个SELinux用户,值为u。
    •r为role的意思。role是角色之意,它是SELinux中一种比较高层次,更方便的权限管理思路,即Role Based Access Control(基于角色的访问控制,简称为RBAC)。简单点说,一个u可以属于多个role,不同的role具有不同的权限。
    •init_exec,代表该文件所属的type为init_exec。如果是进程,该字段通常称为domain。MAC的基础管理思路其实不是针对上面的RBAC,而是所谓的Type Enforcement Accesc Control(简称TEAC,一般用TE表示)。对进程来说,Type就是Domain。Domain有什么权限,都需要政策和规则说明。
    •S0和SELinux为了满足军用和教育行业而设计的Multi-Level Security(MLS)机制有关。简单点说,MLS将系统的进程和文件进行了分级,不同级别的资源需要对应级别的进程才能访问。
    关系示意图

    解释一下这张示意图:当主体想要访问目标时,如果系统中启动了 SELinux,则主体的访问请求首先需要和 SELinux 中定义好的策略进行匹配。如果进程符合策略中定义好的规则,则允许访问,这时进程的安全上下文就可以和目标的安全上下文进行匹配;如果比较失败,则拒绝访问,并通过 AVC(Access Vector Cache,访问向量缓存,主要用于记录所有和 SELinux 相关的访问统计信息)生成拒绝访问信息。如果安全上下文匹配,则可以正常访问目标文件。当然,最终是否可以真正地访问到目标文件,还要匹配产生进程(主体)的用户是否对目标文件拥有合理的读、写、执行权限。

    我们在进行 SELinux 管理的时候,一般只会修改文件或目录的安全上下文,使其和访问进程的安全上下文匹配或不匹配,用来控制进程是否可以访问文件或目录资源;而很少会去修改策略中的具体规则,因为规则实在太多了,修改起来过于复杂。不过,我们是可以人为定义规则是否生效,用以控制规则的启用与关闭的。

    2.1SELinux工作模式

    3种工作模式 
    Enforcing:强制模式。违反SELinux规则的行为将被阻止并记录到日志中。  
    Permissive:宽容模式。违反SELinux 规则的行为只会记录到日志中。一般为调试用。 
    Disabled:关闭SELinux。

    SELinux 提供了 3 种工作模式:Disabled、Permissive 和 Enforcing,而每种模式都为 Linux 系统安全提供了不同的好处。

    Disable工作模式(关闭模式)

    在 Disable 模式中,SELinux 被关闭,默认的 DAC 访问控制方式被使用。对于那些不需要增强安全性的环境来说,该模式是非常有用的。

    例如,若从你的角度看正在运行的应用程序工作正常,但是却产生了大量的 SELinux AVC 拒绝消息,最终可能会填满日志文件,从而导致系统无法使用。在这种情况下,最直接的解决方法就是禁用 SELinux,当然,你也可以在应用程序所访问的文件上设置正确的安全上下文。

    需要注意的是,在禁用 SELinux 之前,需要考虑一下是否可能会在系统上再次使用 SELinux,如果决定以后将其设置为 Enforcing 或 Permissive,那么当下次重启系统时,系统将会通过一个自动 SELinux 文件重新进程标记。


    关闭 SELinux 的方式也很简单,只需编辑配置文件 /etc/selinux/config,并将文本中 SELINUX= 更改为 SELINUX=disabled 即可,重启系统后,SELinux 就被禁用了。

    Permissive工作模式(宽容模式)

    在 Permissive 模式中,SELinux 被启用,但安全策略规则并没有被强制执行。当安全策略规则应该拒绝访问时,访问仍然被允许。然而,此时会向日志文件发送一条消息,表示该访问应该被拒绝。

    SELinux Permissive 模式主要用于以下几种情况:
    审核当前的 SELinux 策略规则;
    测试新应用程序,看看将 SELinux 策略规则应用到这些程序时会有什么效果;
    解决某一特定服务或应用程序在 SELinux 下不再正常工作的故障。

    某些情况下,可使用 audit2allow 命令来读取 SELinux 审核日志并生成新的 SELinux 规则,从而有选择性地允许被拒绝的行为,而这也是一种在不禁用 SELinux 的情况下,让应用程序在 Linux 系统上工作的快速方法。

    Enforcing工作模式(强制模式)

    从此模式的名称就可以看出,在 Enforcing 模式中, SELinux 被启动,并强制执行所有的安全策略规则。

    查看当前工作模式:getenforce

    A101LV:/mnt # getenforce

    Enforcing

    修改工作模式:setenforce

    更改当前的SELINUX的模式值,后面可以跟 enforcing,permissive 或者1,0。

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

    A101LV:/mnt # setenforce 0

    Enforcing:seLinux已经打开;         

    Permissive:seLinux已经关闭;

    setenforce 0(permissive)设置成关闭,setenforce 1(enforcing)设置成打开

    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进行写操作
    allowTEallow语句,表示授权。除了allow之外,还有allowauditdontauditneverallow等。netdsource type。也叫subjectdomain

    proctarget type。它代表其后的file所对应的Type

    file:代表Object Class。它代表能够给subject操作的一类东西。例如FileDirsocket等。在Android系统中,有一个其他Linux系统没有的Object Class,那就是Binder

    write:在该类Object Class中所定义的操作

    Rule Name

      rule_name一共有四种,定义如下:

      1allow:赋予某项权限;

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

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

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

    Type

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

    socket_device

    device

    block_device

    default_service

    system_data_file

    tmpfs

    ….

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

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

      type type_id [attribute_id][attribute_id] ;

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

    例如下面定义了一个名为shelltype,它和一个名为domain的属性(attribute)关联:

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

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

    2attribute:属性,属性其实是一个特殊的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中使用的所有属性;

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

      Typeattribute system mlstrustedsubject;

     关键字           type      attibute

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

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

      b)其实,attribute真正的意思应该是类似typegroup这样的概念。比如将type AattributeB关联起来,就是说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有两种方式:

      1common:其命令的格式为:

      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 }

      2class:除了common外,还有一种class命令也可以设置permsetclass命令可以继承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操作系统,一些原有的命令都进行了扩展,另外还增加了一些新的命令,下面让我们看看经常用到的几个命令:

    1ls -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

    … …

    2ps -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

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

    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

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

    restorecon 1.txt                                                                                                                                                         

    SELinux: Loaded file_contexts

    5id命令使用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

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

    A101LV:/mnt # getenforce

    Enforcing

    7setenforce命令更改当前的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

    EnforcingseLinux已经打开;         

    PermissiveseLinux已经关闭

    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:s0tclass=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 deniedlog不是一次性暴露所有权限问题,要等解决一个权限问题之后,才会暴露另外一个权限问题。比如提示缺少某个目录的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:重启样机即可验证

    展开全文
  • Android SELinux安全策略主要使用对象安全上下文的基础进行描述,通过主体和客体的安全上下文去定义主体是否有权限访问客体,称为TypeEnforcement 安全上下文(Security Context) SEAndroid中的安全上下文:共有4个...
  • 抽时间查阅相关资料后,结合理论知识和源码进行分析,随着在项目中不断处理了一些CTS neverallow的失败项,慢慢地对SELinux有了更深入的理解,接下来的内容将分别介绍基础概念、SELinux开机初始化、SELinux编译相关...
  • 本文实例讲述了Android实现在ServiceManager中加入自定义服务的方法。分享给大家供大家参考,具体如下: 当我们要使用android的系统服务时,一般都是使用Context.getSystemService方法。例如我们要获取AudioManager...
  • Android SELinux语法

    2019-06-10 17:00:30
    SELinux 中,标签采用以下形式:user:role:type:mls_level,其中 type 是访问决定的主要组成部分,可通过构成标签的其他组成部分进行修改。对象会映射到类,对每个类的不同访问类型由权限表示。 政策规则采用以下...
  • Android App Selinux seapp权限详解

    千次阅读 2020-05-07 14:03:43
     selinux/libselinux/src/android/android.c seapp_context_cmp() 7. packages\apps 自定义uid,配置一组apk权限; UID 通过和AID建立对应联系 include/private/android_filesystem_config.h android:...
  • selinux.cpp2.1 SelinuxSetupKernelLogging2.2 SelinuxInitialize2.3 checkreqprot2.4 LoadPolicy2.5 LoadSplitPolicy2.6 FindPrecompiledSplitPolicy二、SELinux Policy编译3. 二进制策略文件的生成
  • Android CTS中neverallow规则生成过程 下面主要分享一些遇到的 CTS neverallow问题的处理方法: 目录一、一些权限的解决方案1.1、区分vendor域和system域1.2、setenforce的可行性1.3、dac_override 解决办法1.4、...
  • 关于Selinux详解

    千次阅读 2020-04-03 09:53:10
    目 录 前绪    2 一、Selinux基础概述    2 二、什么是Selinux?    2 三、SELinux Policy语言  ...
  • 我们在处理SELinux权限问题的时候,avc denied信息是最关键的,那么avc denied 的打印信息要怎么看、里面的内容每一个字段是什么意思?kernel log的avc denied信息是哪里打印出来的? 以前有个想法,我们系统的操作...
  • 6 SELinux 7 加密 等等 其中,加密又分全盘加密(Android 4.4 引入)和文件级加密(Android 7.0 引入),本文将论述加密中的全盘加密的基本知识。全盘加密在 Android 4.4 中引入,在 Android 5.0 中做了比较大的...
  • Android11.0(R) MTK6771 user版本关闭 SELinux

    千次阅读 2021-03-10 13:19:44
    开始我们先来跟一下 selinux 的初始化过程 system\core\init\main.cpp int main(int argc, char** argv) { #if __has_feature(address_sanitizer) __asan_set_error_report_callback(AsanReportCallback); #endif ...
  • Xposed,大名鼎鼎得Xposed,是Android平台上最负盛名的一个框架。在这个框架下,我们可以加载很多插件App,这些插件App可以直接或间接操纵系统层面的东西,...Xposed支持32位和64位的dalvik以及ART,同时支持selinux
  • 浅谈te语法前言1.引言2.基本定义2.1 用type关键字定义类型2.2 用typealias声明别名2.3 attribute关键字声明属性/域2.4 类型与属性/域相关联3....SElinux是Google在android4.3版本上引入的,只不过是默认关闭

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 647
精华内容 258
关键字:

android selinux详解