Android : SELinux 简析&使用

blogs-of-lxl · · 473 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

一 SELinux背景知识

1.  DAC和MAC:

SELinux出现之前,Linux上的安全模型叫DAC,全称是Discretionary Access Control,翻译为自主访问控制。DAC的核心思想很简单,就是:

  • 进程理论上所拥有的权限与执行它的用户的权限相同。比如,以root用户启动Browser,那么Browser就有root用户的权限,在Linux系统上能干任何事情。

显然,DAC太过宽松了,所以各路高手想方设法都要在Android系统上搞到root权限。那么SELinux如何解决这个问题呢?原来,它在DAC之外,设计了一个新的安全模型,叫MAC(Mandatory Access Control),翻译为强制访问控制。MAC的处世哲学非常简单:即任何进程想在SELinux系统中干任何事情,都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限,进程就没有该权限。来看一个SEAndroid中设置权限的例子:

[例子1]

/*

  from external/sepolicy/netd.te

 下面这条SELinux语句表示 允许(allow )netd域(domain)中的进程  ”写(write)“ 

 类型为proc的文件

 注意,SELinux中安全策略文件有自己的一套语法格式,下文我们将详细介绍它

*/

allow netd proc:file write

如果没有在netd.te中使用上例中的权限配置allow语句,则netd就无法往/proc目录下得任何文件中写数据,即使netd具有root权限。

这条语句的语法为:

  • allow:TE的allow语句,表示授权。除了allow之外,还有allowaudit、dontaudit、neverallow等。
  • netd:source type。也叫subject,domain。
  • proc:target type。它代表其后的file所对应的Type。
  • file:代表Object Class。它代表能够给subject操作的一类东西。例如File、Dir、socket等。在Android系统中,有一个其他Linux系统没有的Object Class,那就是Binder。
  • write:在该类Object Class中所定义的操作。

根据SELinux规范,完整的allow相关的语句格式为:rule_name source_type target_type : class perm_set

 

二、 SELinux Policy语言介绍

SELinux中,每种东西都会被赋予一个安全属性,官方说法叫Security Context。Security Context(以后用SContext表示)是一个字符串,主要由三部分组成。例如SEAndroid中,进程的SContext可通过ps -Z命令查看,如图1所示:

以第一个进程/init的SContext为例,其值为u:r:init:s0,其中:

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

再来看文件的SContext,读者可通过ls -Z来查看,如图2所示:

以第一行acct目录为例,其信息为u:object_r:cgroup:s0 :

  • u:同样是user之意,它代表创建这个文件的SELinux user。
  • object_r:文件是死的东西,它没法扮演角色,所以在SELinux中,死的东西都用object_r来表示它的role。
  • cgroup:死的东西的Type,和进程的Domain其实是一个意思。它表示acct目录对应的Type是cgroup
  • s0:MLS的级别。

根据SELinux规范,完整的SContext字符串为:

user:role:type[:range]

注意,方括号中的内容表示可选项。s0属于range中的一部分,MAC基本管理单位是TEAC(Type Enforcement Accesc Control),然后是高一级别的Role Based Accesc Control。RBAC是基于TE的,而TE也是SELinux中最主要的部分。

 

三、Security Labeling:

Android系统启动后(其他Linux发行版类似),init进程会将一个编译完的安全策略文件传递给kernel以初始化kernel中的SELinux相关模块(姑且用Linux Security Module:LSM来表示它把),然后LSM可根据其中的信息给相关Object打标签。

LSM初始化时所需要的信息以及SContext信息保存在两个特殊的文件中,以Android为例,它们分别是:

  • initial_sids:定义了LSM初始化时相关的信息。SID是SELinux中一个概念,全称是Security Identifier。SID其实类似SContext的key值。因为在实际运行时,如果老是去比较字符串(还记得吗,SContext是字符串)会严重影响效率。所以SELinux会用SID来匹配某个SContext。
  • initial_sid_context:为这些SID设置最初的SContext信息。

 

四、  SEAndroid源码分析:

  本节主要看Google是如何在Android平台定制SELinux的。如前文所示,Android平台中的SELinux叫SEAndroid。

1.  编译sepolicy

Android平台中:

  • external/sepolicy:提供了Android平台中的安全策略源文件。同时,该目录下的tools还提供了诸如m4,checkpolicy等编译安全策略文件的工具。注意,这些工具运行于主机(即不是提供给Android系统使用的)
  • external/libselinux:提供了Android平台中的libselinux,供Android系统使用。
  • external/libsepol:提供了供安全策略文件编译时使用的一个工具checkcon。

对我们而言,最重要的还是external/sepolicy。通过如下make命令查看执行情况: mmm external/sepolicy  --just-print

  • sepolicy的重头工作是编译sepolicy安全策略文件。这个文件来源于众多的te文件,初始化相关的文件(initial_sid,initial_sid_context,users,roles,fs_context等)。
  • file_context:该文件记载了不同目录的初始化SContext,所以它和死货打标签有关。
  • seapp_context:和Android中的应用程序打标签有关。
  • property_contexts:和Android系统中的属性服务(property_service)有关,它为各种不同的属性打标签。

 

2.  SEAndroid修改尝试:

通过修改shell的权限,使其无法设置属性。

先来看shell的te,如下所示:

[external/sepolicy/shell.te]

# Domain for shell processes spawned by ADB

type shell, domain;

type shell_exec, file_type;

#shell属于unconfined_domain,unconfined即是不受限制的意思

unconfined_domain(shell)

# Run app_process.

# XXX Split into its own domain?

app_domain(shell)

unconfied_domain是一个宏,它将shell和如下两个attribute相关联:

[external/sepolicy/te_macros]

#####################################

# unconfined_domain(domain)

# Allow the specified domain to do anything.

#

define(`unconfined_domain', `

typeattribute $1 mlstrustedsubject; #这个和MLS有关

typeattribute $1 unconfineddomain;

')

unconfineddomain权限很多,它的allow语句定义在unconfined.te中:

[external/sepolicy/unconfined.te]

......

allow unconfineddomain property_type:property_service set;

从上面可以看出,shell所关联的unconfineddomain有权限设置属性。所以,我们把它改成:

allow {unconfineddomain -shell} property_type:property_service set;

通过一个“-”号,将shell的权限排除。

然后:

  • 我们mmm external/sepolicy,得到sepolicy文件。
  • 将其push到/data/security/current/sepolicy目录下
  • 接着调用setprop selinux.reload_policy 1,使得init重新加载sepolicy,由于/data目录下有了sepolicy,所以它将使用这个新的。

示为整个测试的例子:

  • 重新加载sepolicy之前,笔者可通过"setprop wlan.driver.status test_ok"设置该属性的值为test_ok。
  • 当通过 setprop selinux.reload_policy 1 的命令后,init重新加载了sepolicy。
  • 笔者再setprop wlan.driver.status 都不能修改该属性的值。

示为dmesg输出,可以看出,当selinux使用了data目录下这个新的sepolicy后,shell的setprop权限就被否了!

提示:前面曾提到过audit,日志一类的事情。日志由kernel输出,可借助诸如audit2allow等host上的工具查看哪些地方有违反权限的地方。系统会将源,目标SContext等信息都打印出来。

 

1). 简化方法

1.1 提取所有的avc LOG. 如 adb shell “cat /proc/kmsg | grep avc” > avc_log.txt 
1.2 使用 audit2allow tool 直接生成policy. audit2allow -i avc_log.txt 即可自动输出生成的policy 
1.3 将对应的policy 添加到selinux policy 规则中,对应MTK Solution, 您可以将它们添加在KK: mediatek/custom/common/sepolicy, L: device/mediatek/common/sepolicy 下面,如

  allow zygote resource_cache_data_file:dir rw_dir_perms;
  allow zygote resource_cache_data_file:file create_file_perms;
  ===> mediatek/custom/common/sepolicy/zygote.te (KK)
  ===> device/mediatek/common/sepolicy/zygote.te (L)

注意audit2allow 它自动机械的帮您将LOG 转换成policy, 而无法知道你操作的真实意图,有可能出现权限放大问题,经常出现policy 无法编译通过的情况。

2). 按需确认方法

此方法需要工程人员对SELinux 基本原理,以及SELinux Policy Language 有了解. 
2.1 确认是哪个进程访问哪个资源,具体需要哪些访问权限,read ? write ? exec ? create ? search ? 
2.2 当前进程是否已经创建了policy 文件? 通常是process 的执行档.te,如果没有,并且它的父进程即source context 无须访问对应的资源,则创建新的te 文件. 
在L 版本上, Google 要求维护关键 security context 的唯一性, 比如严禁zygote, netd, installd, vold, ueventd 等关键process 与其它process 共享同一个security context. 
2.3 创建文件后,关联它的执行档,在file_contexts 中, 关联相关的执行档. 
比如 /system/bin/idmap 则是 /system/bin/idmap u:object_r:idmap_exec:s0 
2.4 填写policy 到相关的te 文件中 
如果沿用原来父进程的te 文件,则直接添加. 
如果是新的文件,那么首先:

  #==============================================
  # Type Declaration
  #==============================================
  type idmap, domain;
  type idmap_exec, exec_type, file_type;

  #==============================================
  # Android Policy Rule
  #==============================================
  #permissive idmap;
  domain_auto_trans(zygote, idmap_exec, idmap);

然后添加新的policy

  # new policy
  allow idmap resource_cache_data_file:dir rw_dir_perms;
  allow idmap resource_cache_data_file:file create_file_perms;

3). 权限放大情况处理

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

  <7>[11281.586780] avc:  denied { read write } for pid=1217 
comm="mediaserver" name="tfa9897" dev="tmpfs" ino=4385 
scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 
tclass=chr_file permissive=0

如果直接按照此LOG 转换出SELinux Policy: allow mediaserver device:chr_file {read write}; 那么就会放开mediaserver 读写所有device 的权限. 而Google 为了防止这样的情况, 使用了neverallow 语句来约束, 这样你编译sepolicy 时就无法编译通过. 
为了规避这种权限放大情况, 我们需要细化访问目标(Object) 的SELinux Label, 做到按需申请. 通常会由三步构成 
3.1 定义相关的SELinux type. 
比如上述案例, 在 device/mediatek/common/sepolicy/device.te 添加

   type tfa9897_device, dev_type;

3.2 绑定文件与SELinux type. 
比如上述案例, 在 device/mediatek/common/sepolicy/file_contexts 添加

/dev/tfa9897(/.*)? u:object_r:tfa9897_device:s0

3.3 添加对应process/domain 的访问权限. 
比如上述案例, 在 device/mediatek/common/sepolicy/mediaserver.te 添加

allow mediaserver tfa9897_device:chr_file { open read write };

那么哪些访问对象通常会遇到此类呢?(以L 版本为例) 

  • File 类型: 
    – 类型定义: external/sepolicy/file.te;device/mediatek/common/sepolicy/file.te 
    – 绑定类型: external/sepolicy/file_contexts;device/mediatek/common/sepolicy/file_contexts

  •  device 
    – 类型定义: external/sepolicy/device.te;device/mediatek/common/sepolicy/device.te 
    – 类型绑定: external/sepolicy/file_contexts;device/mediatek/common/sepolicy/file_contexts
  • 虚拟File 类型: 
    – 类型定义: external/sepolicy/file.te;device/mediatek/common/sepolicy/file.te 
    – 绑定类型: external/sepolicy/genfs_contexts;device/mediatek/common/sepolicy/genfs_contexts

  • Service 类型: 
    – 类型定义: external/sepolicy/service.te; device/mediatek/common/sepolicy/service.te 
    – 绑定类型:external/sepolicyservice_contexts;device/mediatek/common/sepolicy/service_contexts

  • Property 类型: 
    – 类型定义: external/sepolicy/property.te;device/mediatek/common/sepolicy/property.te 
    – 绑定类型: external/sepolicy/property_contexts;device/mediatek/common/sepolicy/property_contexts;

    通常我们强烈反对更新google default 的policy, 大家可以更新mediatek 下面的相关的policy.

本文来自:博客园

感谢作者:blogs-of-lxl

查看原文:Android : SELinux 简析&使用

473 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet