Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1292018
  • 博文数量: 478
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 4833
  • 用 户 组: 普通用户
  • 注册时间: 2014-06-28 11:12
文章分类

全部博文(478)

文章存档

2019年(1)

2018年(27)

2017年(21)

2016年(171)

2015年(258)

我的朋友

分类: Android平台

2017-10-31 13:53:41

http://blog.csdn.net/modianwutong/article/details/43114883

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策略


DAC和MAC


  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:file write;

  如果没有在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:file write;

  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_set;

  1)如果有多个source_type,target_type,class或perm_set,可以用”{}”括起来;       注意:使用allow语句的时候,可以使用下面的一些小技巧来简化命令书写;

  2)”~”号,表示除了”~”以外;

  3)”-”号,表示去除某项内容;

  4)”*”号,表示所有内容

  下面就让我们先看几个例子吧:


   Example 1:

  allow appdomain zygote_tmpfs:file read;

  允许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 }:dir relabelto;

  ”-”符号表示去除某项,即允许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语句;


2.Type

  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, domain;

  type sysfs, fs_type, sysfs_type;

  注意:一个type可以关联多个attribute;

  2)attribute:属性由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的时候,直接将其和某个attribute关联起来,也可以单独通过typeattribute命令将某个type和某个或多个attribute关联起来,如下:

  Typeattribute system mlstrustedsubject;

  特别注意:对于初学者而言,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_test;

  type t_b, attr_test;

  # 通过一条allow语句为attr_test设置对t_c类型文件的读权限

  allow attr_test t_c:file read;

  好了,现在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类型关联起来:

  role r;

  role r types domain;

  再来看user的定义:

  user u roles { r } level s0 range s0 - mls_systemhigh;

  声明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:

 

 

   

 

 

 

 

   

 

  接下来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:file execute;

  # 然后,你需要告诉SELinux,允许init域的进程切换到init_shell域

  allow init init_shell:process transition;

  # 最后,你还得告诉SELinux,域切换的入口(entrypoint)是执行shell_exec类型的文件

  allow init_shell shell_exec:file entrypoint;

  看起来挺麻烦,不过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:process transition;

  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_perms;

  allow $1 $3:notdevfile_class_set create_file_perms;

  allow $1 $3:dir create_dir_perms;

  ')

  # 定义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


5)id命令

使用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                                                  

Enforcing


7)setenforce命令

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


SEAndroid实战


  通过上面的讲解,各位应该对SELinux安全策略有了一定的了解,接下来我们看看在具体项目开发中,我们应该如何应对安全策略相关的问题。


定制符合项目需求的安全策略


  SELinux的安全检查覆盖了所有重要的系统资源,每次MAC访问失败都会记录在内核中,如下:

  <6>[82.950769] type=1400 audit(1882976.149: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_perms;

  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(3635791.670: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_perms;

  那么,能不能通过打标签的方法,把/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测试项。

       kernel

       sdcardd

       init_shell

       … …

       security_file

      

              create

              setattr

      

  看来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策略:http://blog.csdn.net/xbalien29/article/details/19505575

  SEAndroid安全机制框架分析http://blog.csdn.net/luoshengyang/article/details/37613135

  SELinux策略配置语言:http://blog.csdn.net/miroku_it/article/details/3685334

  SELinux:百度百科

阅读(3361) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~