SELinux与SEAndroid(一)

起因

最近项目中偶然遇到以下权限问题:

<4>[ 16.770785] type=1400 audit(1471402121.849:35): avc: denied
{ add_name }
for pid=1728 comm="system_server" name="pmops" scontext=u:r:system_server:s0 tcontext=u:object_r:securespaces_file:s0 tclass=dir permissive=0

log中出现avc: denied 相关的信息就是Se机制做的相关权限限制。于是想深入研究以下SE权限机制。希望本文可以帮助大家轻松修改相关安全权限的文件,进一步在安全方面定制自己的Android系统。

背景

SEAndroid是Google在Android 4.4上正式推出的一套以SELinux为基础于核心的系统安全机制。而SELinux则是由美国NSA(国安局)和一些公司(RedHat、Tresys)设计的一个针对Linux的安全加强系统。
NSA最初设计的安全模型叫FLASK,全称为Flux Advanced Security Kernel(由Uta大学和美国国防部开发,后来由NSA将其开源),当时这套模型针对DTOS系统。后来,NSA觉得Linux更具发展和普及前景,所以就在Linux系统上重新实现了FLASK,称之为SELinux。
Linux Kernel中,SELinux通过Linux Security Modules实现。在2.6之前,SElinux通过Patch方式发布。从2.6开始,SELinux正式入驻内核,成为标配。

SELinux背景知识

先问大家一个问题,如果你搞到了Android的root权限,你就真的可以为所欲为了?不妨往下看:
SELinux出现之前,Linux上的安全模型叫DAC,全称是Discretionary Access Control,翻译为自主访问控制。DAC的核心思想很简单,就是:
进程理论上所拥有的权限与执行它的用户的权限相同。比如,以root用户启动Browser,那么Browser就有root用户的权限,在Linux系统上能干任何事情。
显然,DAC太过宽松了,所以各路高手想方设法都要在Android系统上搞到root权限。那么SELinux如何解决这个问题呢?原来,它在DAC之外,设计了一个新的安全模型,叫MAC(Mandatory Access Control),翻译为强制访问控制。MAC的处世哲学非常简单:即任何进程想在SELinux系统中干任何事情,都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限,进程就没有该权限。就是说即使你ROOT了,想干一些事情也是不行的,ROOT已经不是万能神了。
那SE权限需要怎么添加呢?我们来看一个例子:

/*
  from external/sepolicy/netd.te
 下面这条SELinux语句表示 允许(allow )netd域(domain)中的进程  ”写(write)“
 类型为proc的文件
 注意,SELinux中安全策略文件有自己的一套语法格式,下文我们将详细介绍它
*/
allow netd proc:file write

如果没有在netd.te中使用上例中的权限配置allow语句,则netd就无法往/proc目录下得任何文件中写数据,即使netd具有root权限。
显然,MAC比DAC在权限管理这一块要复杂,要严格,要细致得多。
那么,关于DAC和MAC,此处笔者总结了几个知识点:
Linux系统先做DAC检查。如果没有通过DAC权限检查,则操作直接失败。通过DAC检查之后,再做MAC权限检查。
SELinux中也有用户的概念,但它和Linux中原有的user概念不是同一个东西。什么意思呢?比如,Linux中的超级用户root在SELinux中可能就是一个没权限,没地位,打打酱油的”路人甲“。当然,这一切都由SELinux安全策略的制定者来决定。

SELinux Policy语法介绍

Linux中有两种东西,一种死的(Inactive),一种活的(Active)。死的东西就是文件(Linux哲学,万物皆文件。注意,万不可狭义解释为File),而活的东西就是进程。此处的“死”和“活”是一种比喻,映射到软件层面的意思是:进程能发起动作,例如它能打开文件并操作它。而文件只能被进程操作。
SELinux中,每种东西都会被赋予一个安全属性,官方说法叫Security Context。Security Context(以后用SContext表示)是一个字符串,主要由三部分组成。例如SEAndroid中,进程的SContext可通过ps -Z命令查看
SELinux与SEAndroid(一)_第1张图片

最左边的那一列是进程的SContext,以第一个进程/system/bin/logwrapper的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将系统的进程和文件进行了分级,不同级别的资源需要对应级别的进程才能访问。后文还将详细介绍MLS。

再来看文件的SContext,读者可通过ls -Z来查看
SELinux与SEAndroid(一)_第2张图片

倒数第二列所示为根目录下几个文件和目录的SContext信息,以第一行root目录为例,其信息为u:object_r:rootfs:s0:
u:同样是user之意,它代表创建这个文件的SELinux user。
object_r:文件是死的东西,它没法扮演角色,所以在SELinux中,死的东西都用object_r来表示它的role。
rootfs:死的东西的Type,和进程的Domain其实是一个意思。它表示root目录对应的Type是rootfs。
s0:MLS的级别。

到这里应该就知道刚开始我遇到的问题该怎么解决了,添加如下权限即可:
allow system_server securespaces_file:dir add_name

你可能感兴趣的:(深入理解Android)