手机老是出现systempropertytest停止运行_百度知道
手机老是出现systempropertytest停止运行
麻烦死了，我就格式化了下最近手机越来越卡。求大神教下怎么把那个对话框弄掉。每次都要去点下，可是现在一开机就出现那个systempropertytest停止运行的对话框。三星gm3608
在电脑上安装好“刷机精灵”。望采纳，将手机用数据线连接到电脑上，运行“刷机精灵”即可按照提示进行自动的系统刷机了系统有问题了，刷机吧
来自团队：
其他类似问题
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁3870人阅读
Security（2）
SEAndroid简介
& SEAndroid是Google在Android4.4上正式推出的一套以SELinux为核心的系统安全机制。而SELinux则是由NSA（美国国安局）在Linux社区的帮助下设计的一个针对Linux的安全强化系统。
& NSA最初设计的安全模型叫FLASK，全称为FluxAdvanced Security Kernel（由Uta大学和美国国防部开发，后来由NSA将其开源），当时这套模型针对DTOS系统。后来NSA觉得Linux更具发展和普及前景，所以就在Linux系统上重新实现了FLASK，并称之为SELinux。
& SELinux是一种基于域-类型（domain-type）模型的强制访问控制（MAC）安全系统，在LinuxKernel中，SELinux通过LSM（LinuxSecurity Modules）实现。在2.6以前的版本，SELinux通过patch方式发布。从2.6开始，SELinux正式进入内核，成为标配。
& 由于Linux有多种发行版本，所以各家的SELinux表现形式也略有区别，具体到Android平台，Google对其进行了一定的修改，从而得到SEAndroid。
SEAndroid架构
& SEAndroid在架构和机制上与SELinux完全一样，考虑到移动设备的特点，所以移植到Android上的只是SELinux的一个子集。SEAndroid的安全检查几乎覆盖了所有重要的系统资源，包括域转换，类型转换，进程、内核、文件、目录、设备，App，网络及IPC相关的操作。
& 接下来，我们就来看一下SEAndroid安全机制的整体框架，如下所示：图1.SEAndroid安全机制框架
从上面的架构图可以看出来，SEAndroid安全机制包含用户空间和内核空间两部分，内核空间主要涉及LSM内核安全模块，用户空间包括SecurityContext，Security Policy等模块。这些模块的作用和交互如下：
1）LSM提供了一种通用的安全框架，允许将安全模型以模块方式载入内核，除了selinux外，linux还支持tomoyo，yama等安全模型；
2）AVC是一个策略缓存，当进程试图访问系统资源的时候，kernel中的安全策略服务将会先在AVC中查找策略，如果没有命中，则会到安全服务器中查找，找到了，则权限被缓存，允许访问，如果没找到，则拒绝访问；
3）SecurityPolicy描述系统资源的安全访问策略，系统启动时init进程负责把策略文件加载到内核的LSM模块中；
4）SecurityContext描述系统资源的安全上下文，SELinux的安全访问策略就是在安全上下文的基础上实现的；
5）libselinux为用户空间提供了SELinux文件系统访问接口；
SEAndroid策略
& SELinux出现之前，Linux的安全模型叫DAC，全称是DiscretionaryAccess Control，翻译为自主访问控制。DAC的核心思想很简单，就是：
& 进程理论上所拥有的权限与运行它的用户权限相同。比如，以root用户启动shell，那么shell就有root用户的权限，在Linux系统上能干任何事。
& 显然DAC的管理太宽松了，所以各路高手都想方设法要在Android上搞到root权限。事实上su就是通过修改uid(0)和gid(0)的方式来取得root权限的。那么SELinux又是如何解决这个问题的呢？原来，它在DAC之外，设计了一个新的安全模型，叫做MAC（MandatoryAccess Control），翻译为强制访问控制。MAC的处世哲学非常简单，即：
& 任何进程想在SELinux系统中干任何事，都必须先在安全策略的配置文件中赋予权限。凡是没有在安全策略中配置的权限，进程就没有该项操作的权限。来看一个SEAndroid中设置权限的例子：
& [external/sepolicy/netd.te]
& allow netd sysfs:
& 如果没有在netd.te中使用上例中的权限配置语句，那么netd就无法往sys目录下的任何文件中写入数据，即使netd具有root权限。& 上面这条表示允许（Allow）netd域（Domain）中的进程写（Write）sysfs类型（Type）的文件；
& 显然，MAC比DAC在权限管理方面要复杂，严格和细致得多。
& 那么，关于DAC和MAC，两者是什么关系呢？
& 1）Linux系统先做DAC检查。如果没有通过DAC权限检查，则操作直接失败。通过DAC检查之后，再做MAC权限检查；
& 2）SELinux中也有用户的概念，但它和Linux中原有的user概念不是同一个东西。什么意思呢？比如，Linux中的超级用户root在SELinux中可能就是一个没权限，没地位，打打酱油的“路人甲”。当然，这一切都是由SELinux安全策略来决定的。
& 通过上面内容的学习，各位应该能够感觉到，在SELinux中，安全策略文件是最重要的，确实如此，学习SELinux的终极目标应该是：
& 1）看懂现有的安全策略文件；
& 2）编写符合项目需求的安全策略文件；
& SELinux有自己的一套规则来编写安全策略文件，这套规则被称为SELinux安全策略语言，它是掌握SELinux的重点；
& Linux中有两种东西，一种死的（Inactive），一种活的（Active）。死的东西就是指文件（Linux哲学，万物皆文件），而活的东西就是进程。此处的“死”和“活”是一种比喻，映射到软件层面的意思就是：进程能发起动作，例如它能打开并操作文件，而文件只能被进程操作。
& SELinux中，每种东西都会被赋予一个安全属性，它就是SecurityContext，Security Context（以下简称SContext，安全上下文或安全属性）是一个字符串，主要由三部分组成。例如在SEAndroid中，进程的SContext可以通过PS-Z命令查看，如下：
& u:r:init:s0 & & & & & & & & & & & & & & &root & & & &&464 & & &&1&&&& /system/bin/sh
& u:r:healthd:s0 & & & & & & & & & & &root & & & &&240 & & &&1&&&& /sbin/healthd
& u:r:lmkd:s0 & & & & & & & & & & & & &&root & & & &&241&& &&&&1&&&& /system/bin/lmkd
& u:r:servicemanager:s0 & & &system &&242&& &&&&1&&&& /system/bin/servicemanager
& u:r:vold:s0 & & & & & & & & & & & & & &&root & & & &&243&& &&&&1&&&& /system/bin/vold
& u:r:surfaceflinger:s0 & & & & &&system &&244&& &&&&1&&&& /system/bin/surfaceflinger
& 1）u为user的意思：SEAndroid中定义了一个SELinux用户，值为u；& 最左边那一列就是进程的SContext，以第一个进程/system/bin/sh的SContex为例，其值为u:r:init:s0：
& 2）r为role的意思：role是角色之意，它是SELinux中一种比较高层次，更方便的权限管理思路，即RoleBased Access Control（基于角色的访问控制，简称RBAC）。简单点说，一个user可以属于多个role，不同的role具有不同的权限。
& 3）init代表进程在init域（Doamin）中。MAC的基础管理思路其实不是上面的RBAC，而是所谓的TypeEnforcement Access Control（简称TEAC，一般用TE表示）。对进程来说Type就是Domain，比如init这个Domain有什么权限，都需要在策略文件（init.te）中定义。
& 4）s0和SELinux为了满足军用和教育行业而设计的Multi-LevelSecurity（MLS）机制有关。简单点说，MLS将系统的进程和文件进行了分级，不同级别的资源需要对应级别的进程才能访问。
& 再来看看文件的SContext，这里我们用ls -Z来查看，如下：
& drwx------ & &root & &root & & & & &&u:object_r:rootfs:s0 & & & & & & &root
& -rw-r--r-- & & root & &root & & & & &&u:object_r:rootfs:s0 & & & & & & &service_contexts
& 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
& 倒数第二列就是文件和目录的SContext信息，以第一行root目录为例，其值为u:object_r:rootfs:s0：&&&&&& 再来看看文件的SContext，这里我们用ls-Z来查看，如下：
& 1）u还是user的意思；
& 2）object_r：文件是死的东西，它没办法扮演任何角色，所以在SELinux中，所有死的东西都用object_r来表示它的role；
& 3）rootfs代表文件的类型（Type），和进程的Domain其实是一个意思。它表示root目录对应的Type是rootfs；
& 4）s0：MLS的级别；
& 根据SELinux规范，完整的SContext字符串为：
& user:role:type[:range]
& 注意：方括号中的内容表示可选项。S0属于range中的一部分。
& SContext的核心其实是前三个部分：user:role:type
& 前面说了，MAC的管理核心是TEAC，然后是高一级的RBAC。RBAC是基于TE的，而TE也是SELinux中最主要的部分，下面我们就来看看TE。
& 我们再来看看前面提到的权限设置语句：
& allow netd sysfs:
& 1）allow：表示授权。除了allow之外，还有allowaudit、dontaudit、neverallow等；&&&&&& 这条语句的语法为：
& 2）netd：sourcetype，也叫Domain，Subject。
& 3）sysfs：targettype，它代表其后的file所对应的Type。
& 4）file：objectclass，它代表能够给Domain操作的对象。例如file、dir、socket等，Android中SecurityClass的定义在security_classes中。在Android系统中，有一些特殊的Class，如property_service，binder等。
& 5）write：在该类objectclass中所定义的操作，例如file类支持ioctl，read，write等操作。access_vectors中定义了所有objectclass支持的操作。
& 根据SELinux规范，完整的allow语句格式为：
&&rule_name source_type target_type:class perm_
& 1）如果有多个source_type，target_type，class或perm_set，可以用”{}”括起来；&&&&&& 注意：使用allow语句的时候，可以使用下面的一些小技巧来简化命令书写；
& 2）”~”号，表示除了”~”以外；
& 3）”-”号，表示去除某项内容；
& 4）”*”号，表示所有内容
& 下面就让我们先看几个例子吧：
& &Example 1：
& allow appdomain zygote_tmpfs:
&&允许appdomain域的进程对zygote_tmpfs类型的文件（file）执行read操作；
& rule_name：allow；
& soruce_type：appdomain；
& target_type：zygote_temfs；
& object_class：file；
& access_vector：read；
&&Example 2：
&&allow zygote appdomain:process { getpgid setpgid };
&&允许zygote域的进程对appdomain类型的进程执行getpgid和setpgid操作；
& rule_name：allow；
& soruce_type：zygote；
& target_type：appdomain；
& objectclass：process；
& accessvector：getpgid setpgid；
& “{}”中的内容表示一组type或perm_set，使用”{}”可以简化allow语句的书写，如果不用”{}”，上例就需要两条allow语句来分别设置setpgid和getpgid操作，类似的例子还有很多：
&&Example 3：
& # 允许bluetooth域的进程对tun_device, uhid_device, hci_attach_dev类型的
& # 字符文件（chr_file）执行读写操作；
& allow bluetooth { tun_device uhid_device hci_attach_dev }:chr_file { read write }
& # 允许appdomain域的进程对app_data_file类型的文件（file）和链接（lnk_file）
& # 执行create操作；
& allow appdomain app_data_file:{ file lnk_file } { create }
&&Example 4：
& allow init {
& & shell_data_file
& & app_data_file
& }:{ chr_file file } ~{entrypoint execute_no_trans execmod execute relabelto};
& Example4中使用了”~”符号，表示允许init域的进程对shell_data_file,app_data_file类型的字符文件（chr_file），普通文件（file）执行除了entrypointexecute_no_trans execmod execute relabelto以外的操作；
&&Example 5：
&&allow init { file_type -system_file }:
& ”-”符号表示去除某项，即允许init域的进程对file_type类型中除了system_file类型外的目录执行relabelto操作；
& file_type其实是一个类型的集合，所有文件相关的类型都可以包含在这个集合中，如system_file，system_data_file，apk_data_file等，SELinux之所以有类型集合的概念也是为了简化安全策略语言的书写，如上例所示，所有对file_type类型设置的权限策略，都适用于包含在file_type集合中的所有类型，也就是说init域的进程可以对包含在file_type集合中的所有类型（system_data_file，apk_data_file等）的目录执行relabelto操作，system_file类型除外。&&&&&&
”-”符号表示去除某项，即允许init域的进程对file_type类型中除了system_file类型外的目录执行relabelto操作；
&&Example 6：
& allow system_server self:netlink_selinux_socket *;
&&&”*”符号表示所有内容，即system_server域的进程能够对system_server类型执行所有netlink_selinux_socket类相关的操作；
& self表示targettype与source type相同，这时就不用再重复写一遍sourcetype了，用self代替就可以了； & & &
& 好，下面来个稍微复杂点的：
&&Example 7：
& neverallow {
& & domain -keystore
& } keystore_data_file:dir ~{ open create read getattr setattr search relabelto };
&&简单来说就是不允许除keystore域外的其它域对keystore_data_file类型的目录执行open，create等操作；
& 特别注意，前面提到权限必须显示声明，没有声明的话默认就没有权限。那么neverallow语句就没有存在的必要了，因为“无权限”是不需要声明的。确实如此，neverallow语句的作用只是在生成安全策略文件时进行检查，判断是否有违反neverallow语句的策略存在。
& 下面我们为init_shell添加对keystore_data_file类型目录访问的权限，显然这是违反Example7中neverallow规则的，那么，在生成安全策略文件时就检测到了冲突，如下：
& out/host/linux-x86/bin/checkpolicy:& loading policy configuration from out/target/product/xxx/obj/ETC/sepolicy_intermediates/policy.conf libsepol.check_assertion_helper: neverallow on line 24 of external/sepolicy/keystore.te (or line 7122 of policy.conf)
violated by allow init_shell keystore_data_file:dir { open };
& Error while expanding policy
& make: *** [out/target/product/xxx/obj/ETC/sepolicy.recovery_intermediates/sepolicy.recovery] Error 1
& 在编译policy.conf时，检测到有违反keystore.te第24行neverallow规则的allow语句存在；从编译日志也能看出来，安全策略文件保存在obj/ETC/sepolicy_intermediates目录下；
& 看了上面几个例子，是不是觉得安全策略语言很简单啊，下面让我们再深入一点，看看allow语句各个字段的含义吧。
1.Rule Name
& rule_name一共有四种，定义如下：
& 1）allow：赋予某项权限；
& 2）allowaudit：audit含义就是记录某项操作，默认情况下SELinux只记录那些权限检查失败的操作。allowaudit则使得权限检查成功的操作也被记录。注意：allowaudit只是允许记录，它和赋予权限没有关系。赋予权限必须且只能使用allow语句。
& 3）dontaudit：对那些权限检查失败的操作不做记录；
& 4）neverallow：检查安全策略文件中是否有违反该项操作的allow语句；
& SELinux是基于Domain-Type的强制类型访问模型，Domain其实也是Type，它只是对进程类型的习惯称呼，和Type相关的命令主要由三个：
& 1）type：类型声明，type命令的完整格式为：
& type type_id [attribute_id][attribute_id] …;
& 其中方括号中的内容为可选项，attribute_id表示与type_id相关联的属性；
& 下面的例子定义了一个名为shell的type，它和一个名为domain的属性（attribute）关联：
& type shell,
& type sysfs, fs_type, sysfs_
& 注意：一个type可以关联多个attribute；
& 2）attribute：属性由attribute关键字声明，属性其实是一个特殊的type，可以把属性看成是type的集合，为属性设置的策略，适用于所有与该属性相关联的type，如下：
& attribute fs_&&&&&&&&&&&&&&& # 声明fs_type属性
& attribute sysfs_&&&&&&&&& # 声明sysfs_type属性
& # 允许init进程对sysfs_type类型集合的所有目录，文件执行relabelto操作
& allow init sysfs_type:{ dir file lnk_file }
&&注意：attributes文件中定义了SEAndroid中使用的所有属性；
& 3）typeattribute：可以在定义type的时候，直接将其和某个attribute关联起来，也可以单独通过typeattribute命令将某个type和某个或多个attribute关联起来，如下：
&&Typeattribute syst
&&特别注意：对于初学者而言，attribute和type的关系最难理解，因为”attribute”这个关键字实在没取好名字，很容易产生误解：
& a）实际上，type和attribute位于同一个命名空间，即不能用type命令和attribute命令定义相同名字的东西；
& b）其实，attribute真正的意思应该是类似typegroup这样的概念。比如将type A和attributeB关联起来，就是说type A属于attributeB中的一员；
& 使用attribute有什么好处呢？一般而言，系统会定义数十或数百个type，每个type都需要通过allow语句来设置相应的权限，这样我们的安全策略文件编写起来就会非常麻烦。有了attribute之后呢，我们可以将这些type与某个attribute关联起来，把这些type共有的权限，通过一条allow语句来设置：
& # 定义两个type，分别是t_a和t_b，它们都需要设置对t_c类型文件的读操作；
& # 首先，把t_a和t_b关联到attr_test
& type t_a, attr_
& type t_b, attr_
& # 通过一条allow语句为attr_test设置对t_c类型文件的读权限
& allow attr_test t_c:
& 好了，现在t_a和t_b域的进程拥有了对t_c类型文件的读权限
3.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
& class binder&&&&& # Android平台特有的binder
& class zygote&&&&& # Android平台特有的zygote
& class property_service& # Android平台特有的属性服务
4.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 }
RBAC（选读）
& 绝大多数情况下，SELinux的安全策略需要我们编写各种各样的te文件。由前文可知，.te文件内部应该包含了各种allow， type等语句。这些都是TEAC，属于SELinux MAC中的核心组成部分
& 在TEAC之上，SELinux还有一种基于角色的安全策略，也就是RBAC。RBAC到底是如何实施相关权限控制的呢？我们先来看看SEAndroid中Role和User的定义。
& Android中只定义了一个role，就是r，把r和domain类型关联起来：
& 再来看user的定义：
&&user u roles { r } level s0 range s0 - mls_
& 声明useru，并且和role r关联起来，level表示u的安全级别，s0为最低级，也就是默认的级别。mls_systemhigh表示u所能获得的最高安全级别；
& 那么，Role和User之间有什么样的权限控制呢？
& 在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。
标记安全上下文
& 前面陆陆续续的讲了些SELinux中最常见的东西，不过细心的人可能会问这样一个问题：这些安全属性（SContext）最开始是怎么赋给这些死的和活的东西呢？
& 在SELinux中，设置或分配SContext给进程或文件的工作叫做SecurityLabeling，土语叫打标签。
& Android系统启动后，init进程会调用selinux_android_load_policy接口，将一个编译完的安全策略文件传递给内核，内核可根据其中的相关信息来初始化SELinux相关模块；接着init进程会调用selinux_android_restorecon接口，根据context文件中的信息为系统打标签；
& context文件中显示声明了系统中各种资源的安全属性，下面就来看看SEAndroid中用到的几种context文件：
1.为文件或文件系统打标签
1）file_contexts：为系统中的各种文件，目录设置初始的SContext，如下：
& /dev(/.*)? & & & & & & & & & & & & u:object_r:device:s0
& /dev/akm8973.* & & & & & & u:object_r:sensors_device:s0
& /dev/accelerometer & & & u:object_r:sensors_device:s0
& /dev/adf[0-9]* & & & & & & & & &u:object_r:graphics_device:s0
& /dev/alarm & & & & & & & & & & & u:object_r:alarm_device:s0
& /dev/android_adb.* & & & &u:object_r:adb_device:s0
& /dev/ashmem & & & & & & & & u:object_r:ashmem_device:s0
& /dev/audio.* & & & & & & & & & & u:object_r:audio_device:s0
& /system(/.*)? & & & & & & & & & u:object_r:system_file:s0
& /system/bin/sh & & & -- & & &u:object_r:shell_exec:s0
& /system/bin/run-as & -- & u:object_r:runas_exec:s0
& /system/bin/bootanimation &u:object_r:bootanim_exec:s0
2）fs_use：描述SELinux的Labeling信息在不同文件系统时的处理方式。对于常规文件系统，SContext信息保存在文件节点（inode）的属性中，系统可以通过getattr函数从inode中读取到文件的安全属性。
& fs_use_xattr关键字表示SContext是永远性的保存在文件系统中：
& # Label inodes via getxattr.
& fs_use_xattr &&& yaffs2 &&&&&&& u:object_r:labeledfs:s0;
& fs_use_xattr &&& jffs2 &&&&&&&&&&& u:object_r:labeledfs:s0;
& fs_use_xattr &&& ext2 &&&&&&&&&&& u:object_r:labeledfs:s0;
& fs_use_xattr &&& ext3 &&&&&&&&&&& u:object_r:labeledfs:s0;
& fs_use_xattr &&& ext4 &&&&&&&&&&& u:object_r:labeledfs:s0;
3）genfs_contexts：文件系统还可以使用genfscon关键字来打标签，如下：
& # Label inodes with the fs label.
& genfscon & rootfs &&&&&&&& / &&&&&&&&&& u:object_r:rootfs:s0
& genfscon & proc &&&&&&&&&& / &&&&&&&&&& u:object_r:proc:s0
& genfscon & proc&&&&&&&&&&&& /net &&&& u:object_r:proc_net:s0
& genfscon & sysfs&&&& &&&& / &&&&&&&&&& u:object_r:sysfs:s0
& genfscon & vfat&&&&&&&&&&&&&& / &&&&&&&&&& u:object_r:vfat:s0
& genfscon & debugfs&&&&& / &&&&&&&&&& u:object_r:debugfs:s0
& genfscon & fuse &&&&&&&&&& / &&&&&&&&&& u:object_r:fuse:s0
2.为property打标签
& SEAndroid还增加为property打标签的功能，如下property_contexts文件：
& ril.&&&&&&&&&&&& &&&& u:object_r:radio_prop:s0
& gsm.&&&&&&&&&& &&&& u:object_r:radio_prop:s0
& sys.&&&&&&&&&& &&&&& u:object_r:system_prop:s0
& sys.powerctl&& &&&&&& u:object_r:powerctl_prop:s0
& *&&&&&&&&&&&&& &&&&& u:object_r:default_prop:s0
3.为service打标签
&&&SEAndroid还支持为service打标签，使用”getprop| grep init.svc”命令，可以查看系统中所有服务的运行状态，系统服务的安全上下文，详见service_context；
4.为app打标签
&&&& 为app打标签，mac_permissions.xml根据apk签名设置app的seinfo，AndroidL只识别platform签名，其它都是default：
& &!-- Platform dev key in AOSP --&
& &signer signature=&@PLATFORM& &
& & &seinfo value=&platform& /&
& &/signer&
& &!-- All other keys --&
& &default&
& & &seinfo value=&default& /&
& &/default&
& 接下来seapp_contexts根据seinfo和user来为app打标签；
& user=system domain=system_app type=system_app_data_file
& user=bluetooth domain=bluetooth type=bluetooth_data_file
& # 三方的apk，如果有platform签名，则运行在platform_app域
& user=_app seinfo=platform domain=platform_app type=app_data_file
& # 三方的apk，如果没有platform签名，则运行在untrusted_app域
& user=_app domain=untrusted_app type=app_data_file
& SEAndroid中，init进程的SContext为u:r:init:s0（在init.rc中使用” setcon u:r:init:s0”命令设置），而init创建的子进程显然不会也不可能拥有和init进程一样的SContext（否则根据TE，这些子进程也就在MAC层面上有了和init进程一样的权限）。那么这些子进程是怎么被打上和父进程不一样的SContex呢？
& 在SELinux中，上述问题被称为DomainTransition，即某个进程的Domain切换到一个更合适的Domain中去。DomainTransition也是在安全策略文件中配置的，而且有相关的关键字。
& 这个关键字就是type_transition，表示类型转换，其完整格式如下：
&&type_transition& source_type& target_type : class& default_type
& 表示source_type域的进程在对target_type类型的文件进行class定义的操作时，进程会切换到default_type域中，下面我们看个域转换的例子：
&&type_transition init shell_exec:process init_shell
& 这个例子表示：当init域的进程执行（process）shell_exec类型的可执行文件时，进程会从init域切换到init_shell域。那么，哪个文件是shell_exec类型呢？从file_contexts文件能看到，/system/bin/sh的安全属性是u:object_r:shell_exec:s0，也就是说init域的进程如果运行shell脚本的话，进程所在的域就会切换到init_shell域，这就是DomainTransition（简称DT）。
& 请注意，DT也是SELinux安全策略的一部分，type_transition不过只是开了一个头而已，要真正实施成功这个DT，还至少需要下面三条权限设置语句：
& # 首先，你得让init域的进程要能够执行shell_exec类型的文件
& allow init shell_exec:
& # 然后，你需要告诉SELinux，允许init域的进程切换到init_shell域
& allow init init_shell:
& # 最后，你还得告诉SELinux，域切换的入口（entrypoint）是执行shell_exec类型的文件
& allow init_shell shell_exec:
& 看起来挺麻烦，不过SELinux支持宏定义，我们可以定义一个宏，把上面4个步骤全部包含进来。在SEAndroid中，所有的宏都定义在te_macros文件中，其中和DT相关的宏定义如下：
& # 定义domain_trans宏，$1,$2,$3代表宏的第一个，第二个…参数
& define(`domain_trans', `
& allow $1 $2:file { getattr open read execute };
& allow $1 $3:
& allow $3 $2:file { entrypoint open read execute getattr };
& # 定义domain_auto_trans宏，这个宏才是我们在te中直接使用的
& define(`domain_auto_trans', `
& # Allow the necessary permissions.
& domain_trans($1,$2,$3)
& # Make the transition occur by default.
& type_transition $1 $2:process $3;
& &呵呵，是不是简单多了，domain_trnas宏在DT需要的最小权限的基础上还增加了一些权限，在te文件中可以直接用domain_auto_trans宏来显示声明域转换，如下：
& domain_auto_trans(init, shell_exec, init_shell)
& 除了DT外，还有针对Type的Transition（简称TT）。举个例子，假设目录A的SContext为u:r:dir_a，那么默认情况下，在该目录下创建的文件的SContext就是u:r:dir_a，如果想让它的SContext发生变化，那么就需要TypeTransition。
& 和DT类似，TT的关键字也是type_transition，而且要顺利完成Transition，也需要申请相关权限，废话不多说了，直接看te_macros是怎么定义TT所需的宏：
& # 定义file_type_trans宏，为Type Transition申请相关权限
& define(`file_type_trans', `
& allow $1 $2:dir ra_dir_
& allow $1 $3:notdevfile_class_set create_file_
& allow $1 $3:dir create_dir_
& # 定义file_type_auto_trans(domain, dir_type, file_type)宏
& # 该宏的意思就是当domain域的进程在dir_type类型的目录创建文件时，该文件的SContext
& # 应该是file_type类型
& define(`file_type_auto_trans', `
& # Allow the necessary permissions.
& file_type_trans($1, $2, $3)
& # Make the transition occur by default.
& type_transition $1 $2:dir $3;
& type_transition $1 $2:notdevfile_class_set $3;
& SELinux支持Disabled，Permissive，Enforce三种模式；
& Disabled就不用说了，此时SELinux的权限检查机制处于关闭状态；
& Permissive模式就是SELinux有效，但是即使你违反了它的安全策略，它让你继续运行，但是会把你违反的内容记录下来。在策略开发的时候非常有用，相当于Debug模式；
& Enforce模式就是你违反了安全策略的话，就无法继续操作下去。
& 在Eng版本使用setenforce命令，可以在Permissive模式和Enforce模式之间切换。
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命令
更改文件的安全属性
root@xxx:/ # ls -Z /dev/tfa9890&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
crw-rw---- media&&& media &&&&& u:object_r:audio_device:s0 tfa9890
root@xxx:/ # chcon u:object_r:device:s0 /dev/tfa9890
root@xxx:/ # ls -Z /dev/tfa9890&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&
crw-rw---- media&&& media &&&&& u:object_r: device:s0&&&&& &&&& tfa9890
4）restorecon命令
当文件的安全属性在安全策略配置文件里面有定义时，使用restorecon命令，可以恢复原来的安全属性
root@xxx:/ # restorecon /dev/tfa9890&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
SELinux: Loaded file_contexts from /file_contexts
root@xxx:/ # ls -Z /dev/tfa9890&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&
crw-rw---- media&&& media&&&&&&& u:object_r:audio_device:s0 tfa9890
使用id命令，能确认自己的SecurityContext
root@xxx:/ # id
uid=0(root) gid=0(root) groups=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) context=u:r:su:s0
6）getenforce命令
得到当前SELinux的模式值
root@xxx:/ # getenforce&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
7）setenforce命令
更改当前的SELINUX的模式值，后面可以跟 enforcing,permissive 或者1,0。
SEAndroid实战
& 通过上面的讲解，各位应该对SELinux安全策略有了一定的了解，接下来我们看看在具体项目开发中，我们应该如何应对安全策略相关的问题。
定制符合项目需求的安全策略
& SELinux的安全检查覆盖了所有重要的系统资源，每次MAC访问失败都会记录在内核中，如下：
& &6&[82.950769] type=1400 audit(:5): avc: denied { write } for pid=3194 comm=&BluetoothAdapte& name=&aplog& dev=&mmcblk0p22& ino=88 scontext=u:r:bluetooth:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir
& 上面的log记录了一条违反安全策略的访问信息，即BluetoothAdapte进程试图在data分区写目录失败。
& scontext表示进程的SContext，u:r:bluetooth:s0，属于bluetooth域；
& tcontext表示目标的SContext，u:r:system_data_file:s0，属于system_data_file类型;
& tclass表示进程要操作的ObjectClass，dir表示目录；
& mmcblk0p22是userdata分区，write表示写操作。
& 连起来就是bluetooth域的进程（BluetoothAdapte），对system_data_file类型的dir执行write操作失败。明确了失败原因，我们就可以在安全策略配置文件中定制我们自己的策略了：
& [external/sepolicy/bluetooth.te]
& allow bluetooth system_data_file:dir w_dir_
& w_dir_perms是一个宏，其定义在global_macros中，包含了write相关操作：
& [external/sepolicy/global_macros]
& define(`w_dir_perms', `{ open search write add_name remove_name }')
为新的设备文件增加安全属性
& 在项目开发中，我们在/dev目录下建立了一个新的设备文件tfa98xx，这是一个音频相关的设备文件，但是在集成framework层的代码后，总是出现下面的访问错误，应该如何处理呢？
& &6&[12.435524] type=1400 audit(:21): avc: denied { read write } for pid=273 comm=&mediaserver& name=&tfa98xx& dev=&tmpfs& ino=9770 scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 tclass=chr_file
& 首先，我们先看一下访问失败的原因：从log看，应该是mediaserver域的进程没有权限读写device类型的字符设备文件。那么我们能不能在mediaserver.te中加入访问权限呢？
& 在domain.te中有如下定义：
& [external/sepolicy/domain.te]
& neverallow { domain -unconfineddomain -ueventd } device:chr_file { open read write };
& 也就是说除了unconfineddomain和uevented域外，所有在domain域中的进程都不能对device类型的字符设备文件执行open，read，write操作。
& mediaserver也属于domain域，所以肯定不能通过添加策略来设置访问权限，怎么办呢？
& 在mediaserver.te中，我们发现mediaserver域是可以对audio_device类型的字符设备执行读写的：
& [external/sepolicy/mediaserver.te]
& allow mediaserver audio_device:chr_file rw_file_
& 那么，能不能通过打标签的方法，把/dev/tfa98xx设置为audio_device类型呢？答案是肯定的。
& 在file_context中设置/dev/tfa98xx的安全属性，问题解决了：
& [external/sepolicy/file_context]
& /dev/tfa9890&&&&& u:object_r:audio_device:s0
CTS相关问题
& Android5.0的CTS测试中已经包含了安全策略相关的测试项：
& runcts -c android.security.cts.SELinuxTest -m testSELinuxPolicyFile
& 测试中出现了下面的错误信息：
& android.security.cts.SELinuxTest#testSELinuxPolicyFile FAIL
& 查看device_logcat，能看到
& System.out: SELinux avc rule neverallow58 failed 2 out of 100 checks.
& neverallow58测试出现2个失败，那么这个neverallow58是个啥呢？
& 先看一下测试用的apk，在android-cts/repository/testcases下有个CtsSecurityTestCases.apk，解压缩后asset目录下有个selinux_policy.xml文件，这个文件里面记录了所有CTS测试项。
&avc_rule name=&58& type=&neverallow&&
&&&&&& &type type=&source&&kernel&/type&
&&&&&& &type type=&source&&sdcardd&/type&
&&&&&& &type type=&source&&init_shell&/type&
&&&&&& … …
&&&&&& &type type=&target&&security_file&/type&
&&&&&& &obj_class name=&dir&&
&&&&&&&&&&&&& &permission&create&/permission&
&&&&&&&&&&&&& &permission&setattr&/permission&
&&&&&& &/obj_class&
& 看来neverallow58就是检查souce定义的这些域中的进程对target类型，也就是security_type类型的目录能否执行create和setattr操作，当然这是neverallow的，也就是不能执行操作才能pass。
& 在external/sepolicy目录看看我们最近的修改，发现为了让init_shell域的进程能够删除/data/security目录，修改了domain.te中的neverallow规则：
& [external/sepolicy/domain.te]
& neverallow { domain -init -system_server -init_shell } security_file:dir { create setattr };
& 看来neverallow的规则，还是不能随便修改的，否则就可能导致CTS测试失败，去掉init_shell，CTS测试PASS；
& [external/sepolicy/domain.te]
& neverallow { domain -init -system_server } security_file:dir { create setattr };
& SEAndroid-for-share.pdf
& SEAndroid策略：
& SELinux策略配置语言：
& SELinux：百度百科
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：13542次
排名：千里之外
原创：15篇
(17)(1)(3)