转自 https://blog.csdn.net/gulinxieying/article/details/78677139#_Toc465344921
目 录
案例一、OTA升级过程中出现/system/etc/ppp/ip-up-vpn无法添加scontext 15
Selinux梳理总结
前绪
该文档只是将selinux中最基础的知识点进行了整理罗列,其他还有很多高级用法及升华拓展部分,如SElinux域转换、角色转换以及SElinux框架等,并未收录,有需要了解的可以参照参考文献部分中的《SElinux详解》文档,后续会继续补充完善。
一、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的安全性和使用性,Google在Android 4.4上正式推出的一套以SELinux为基础于核心的系统安全机制,且命名为SEandroid,自此,selinux便被"移植"到了Android上了。
二、什么是Selinux?
SELinux出现之前,Linux上的安全模型叫DAC,全称是Discretionary Access Control(自主访问控制)。DAC的核心思想很简单,就是:进程理论上所拥有的权限与执行它的用户的权限相同。比如,以root用户启动Browser,那么Browser就有root用户的权限,在Linux系统上能干任何事情。
显然,DAC太过宽松了,所以各路高手想方设法都要在Android系统上搞到root权限。那么SELinux如何解决这个问题呢?原来,它在DAC之外,设计了一个新的安全模型,叫MAC(Mandatory Access Control),翻译为强制访问控制。MAC的处世哲学非常简单:即任何进程想在SELinux系统中干任何事情,都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限,进程就没有该权限。来看一个SEAndroid中设置权限的例子:
[external/sepolicy/netd.te]
/*
允许(allow )netd域(domain)中的进程写(write)类型为proc的文件
*/
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做一个初步的了解,下面将对selinux特有的语法做简单介绍。
三、SELinux Policy语言
在网上看到一种比喻的说法,个人感觉很有道理:Linux中有两种东西,一种死的(Inactive),一种活的(Active)。活的东西就是进程,而死的东西就是资源(eg:文件、套接字等)。他们之间就是一种操作和被操作,或者说使用与被使用的关系。进程能发起动作,例如它能打开文件并操作它。而文件只能被进程操作。SElinux Policy语言就是将死的和活的东西都给打上"标签",通过"标签"将系统内的资源(包括进程)分成不同的角色(比如:用户、客体),进而对整个系统资(包括进程)进行合理安全的管控。
1、安全属性——SContext
在SELinux世界里,每种东西都会被赋予一个安全属性,官方说法叫Security Context,也可以理解为上文所提到的"标签"。通过每个资源的属性,对他们进行归类管理。Security Context(以后用SContext表示)是一个字符串,由四部分组成,被分为两类:进程SContext和资源SContext。根据SELinux规范,完整的SContext字符串为:
user:role:type[:range]
注意,[]中的内容表示可选项。s0属于range中的一部分,表示安全级别(这里不做讨论)。
首先,我们通过下面例子看下进程SContext。如SEAndroid中,进程的SContext可通过ps -Z命令查看,如图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——tyoe,代表该进程所属的Domain为init。MAC的基础管理思路其实不是针对上面的RBAC,而是所谓的Type Enforcement Accesc Control(简称TEAC,一般用TE表示)。对进程来说,Type就是Domain。比如init这个Domain有什么权限,都需要通过[例子1]中allow语句来说明。
-
S0——和SELinux为了满足军用和教育行业而设计的Multi-Level Security(MLS)机制有关。简单点说,MLS将系统的进程和文件进行了分级,不同级别的资源需要对应级别的进程才能访问。限于篇幅,这里不做过多探讨。
接着,我们看下文件的SContext,在SEandriod中,文件的SContext可以通过ls -Z查看:
如上图所示,右边数第二列就是所对应的SContext信息。以root目录为例,其对应SContext为:u:object_r:rootfs:s0:
-
u——同样是user之意,它代表创建这个文件的SELinux user。
-
object_r——role,这里指文件,在SELinux中,使用object_r表示它的role。
-
rootfs——死的东西的Type,和进程的Domain其实是一个意思。它表示root目录对应的Type是rootfs。
-
s0——MLS的级别。
2、TE简介
有了SContext就可以对系统内所有资源进行统一管理了。SElinux的安全模型(MAC)有两种管理机制,分别是TEAC(Type Enforcement Accesc Control,后文简称TE)和RBAC(Role Based Accesc Control)。RBAC是更高级的一种管理机制(由于SEandroid涉及不多,这里不予展开谈论),不过也是基于TE的。可见,TE是SElinux的管理核心,下面我们就对TE语法做详细解读。
在没有介绍具体的语法之前,首先需要了解下与TE语句相关的另外几个概念定义:
1). 客体类别和许可:
客体类别及其许可是 SELinux 中访问控制的基础,客体类别代表资源的范畴,如文件和
套接字,许可代表对这些资源的访问权限,如读或发送。一个客体类别代表某个确定类型(如文件或套接字)的所有资源,一个客体类别的实例(如某个特定的文件或套接字)被称为一个客体。客体类别指的是资源(文件)的所有范畴,客体指的是客体类别的某个特定实例(如: /etc/passwd)。
【声明定义方法】
声明许可有两种方法,第一种叫做通用许可(被多个客体类别所共用),它允许我们创建与客体类别一起作为一个组的许可,通用许可在类似的客体类别(如文件和符号连接)共享一套访问许可时很有用;第二种方法叫做特定类别许可(由某个客体类别所独用),它允许我们单独为客体类别声明特定的许可,正如将会看到的,有一些客体类别只有特定的许可,有一些只有通用许可,还有一些是这两者都有。客体类别和许可定义方法如下:
声明客体类别:class 类别名字
通用许可:common 通用名 {许可集}
联合许可和客体类别:class 类别名 [inherits 通用许可集名] [{许可集}]
此外,既然有客体,肯定还有主体一说,即谁去使用、操作客体。主体和客体只是逻辑上的区别,只有放在安全控制语句中才能看出谁是主体谁是客体。但,既然是控制,主体一般来说肯定是"活的"才有可能去控制"死的"东西,所以,在SEandriod中,主体一般指的就是进程,客体可以是文件等资源,也可以是进程(因为进程一样可以被进程操作)。
2). 访问向量规则:
访问向量规则又称AV规则,属于SElinux策略语言的控制部分。常用的通用AV规则有如下4个:
-
allow:表示允许主体对客体执行允许的操作
-
dontaudit:表示不记录违反规则的决策信息,且违反规则不影响运行(允许操作且不记录)
-
auditallow:表示允许操作并记录访问决策信息(允许操作且记录)
-
neverallow:表示不允许主体对客体执行指定的操作
好了,到此,我们就可以组合成最基本的SElinux策略语句了。一般,完整的基本安全控制语句格式为:
AV规则 主体 客体:客体类别 许可
还拿之前的例子做说明:
allow netd proc:file write
其中:
allow——AV规则
netd——主体
proc——客体
file——客体类别
write——许可
当然,后面还有很多其他策略语句,将在介绍系统文件时,一并概述。
3). AV规则
对于AV规则,前文已经有所提及,比如allow。SElinux中主要的有效规则有allow,auditallow,auditdeny,dontaudit和neverallow,下面逐一介绍。
-
允许规则allow
我们使用allow规则指出了所有运行时授予的许可,它们是SELinux策略中允许许可的唯一方法,注意:默认情况下,不允许任何访问,我们指定了两个类型列表(源和目标类型),根据列出的客体类别的许可指定访问权,如:
allow user_t bin_t : file { read execute };
这个规则允许任何安全上下文中类型具有user_t的进程对任何安全上下文中具有类型为bin_t的普通文件所有read和execute访问权。allow规则共享了通用AV规则的的所有语法,并且也没有增加任何额外的语法了。
-
审核规则auditallow/auditdeny/dontaudit
SELinux有大量的工具记录日志信息,或审核、访问尝试被策略允许或拒绝的信息。审核消息通常叫做"AVC消息",它提供了详细了关于访问尝试的信息,包括是允许还是拒绝,源和目标的安全上下文,以及其它一些访问尝试涉及到资源信息。AVC消息与其它内核消息类似,都是存储在/var/log目录下的日志文件中,它是策略开发、系统管理和系统监视不可缺少的工具。在此,我们检查是哪一个访问尝试产生了审核消息。
默认情况下,SELinux不会记录任何允许的访问检查,只会记录被拒绝的访问检查。这并没什么奇怪的,在大多数系统上,每秒会允许成千上万的访问,只有很少的一部分会被拒绝,允许的访问通常是在预料之中的,通常不需要审核,被拒绝的访问通常是(但不总是)非预期的访问,对它们进行审核便于管理员发现策略的bug和可能的入侵尝试。策略语言允许我们取消这些默认的预料之中的拒绝审核消息,改为记录允许的访问尝试审核消息。
SELinux提供两个AV规则允许我们控制审核哪一种访问尝试:dontaudit和auditallow。使用这两条规则我们就可以改变默认的审核类型了,最常用的是dontaudit规则,它指出哪一个访问尝试被拒绝时不审核,这样就覆盖了SELinux默认的审核所有拒绝的访问尝试的行为。
dontaudit httpd_t etc_t : dir search;
注意,审核(audit)规则让我们覆盖了默认的审核设置,allow规则指出了什么访问是允许的,auditallow规则不允许访问,它只审核允许的许可。
-
禁止规则neverallow
最后一个AV规则是neverallow规则,我们使用这个规则来指定永远不会被allow规则执行的访问,你可能会疑惑,为什么会有这个规则?因为默认情况下所有的访问都是被拒绝的,设计这个规则的主要目的是为了帮助编写策略时,可以明确地指出不想要的访问许可,因此可以预防意外发生,回想一下,在一个SELinux策略中可能包含成千上万条规则,可能不小心加入了我们本不想授予的访问权,此时,neverallow规则就可以帮助预防这种情况发生,如:
neverallow user_t shadow_t : file write;
这条neverallow规则可以有效地阻止我们在策略中添加一条允许user_t对类型为shadow_t的文件进行写操作的规则,如果添加了这样的规则在编译时就会报错,这条规则不会移除访问权,它只是会产生编译错误。我们在编写策略时,neverallow规则往往放在allow规则前面,首先声明哪些访问是明确地被拒绝的,然后再声明哪些访问是可以接受的,这样就可以预防我们人为出错了。
neverallow规则支持一些特殊的其它AV规则不支持的语法,在neverallow规则中的源和目标类型列表中可以使用通配符(*)和求补算操作符(~),如:
neverallow * domain : dir ~{ read getattr };
这条规则指出没有哪条allow可以授予任何类型对具有domain属性的类型的目录有任何访问权,除了read和getattr访问权外(即读访问权),这条规则的中通配符意味着所有的类型,在真实的策略中,类似这样的规则很常见,它们用来阻止对/proc/目录适当的访问。
我们从前面这个例子中看出,在源类型列表中需要使用通配符,因为我们想要指出任何类型或所有类型,包括那些还没有创建的类型,使用通配符可以预防我们未来犯错。
另一个常见的neverallow规则是:
neverallow domain ~domain : process transition;
这条neverallow规则增强了domain属性,它指出了进程不能转换到无domain属性的类型,这就使得要为一个类型无doamin属性的进程创建一个有效的策略是不可能的。
四、SElinux策略文件
SElinux的策略文件主要集中在external\sepolicy下,这里也是我们添加修改安全策略的主要地方。这里所有的安全策略在编译后最终都会汇集到out/target/product/generic/obj/ETC/sepolicy_intermediates/policy.conf文件中,然后再经过转化load到linux kernel。下面我们就对external\sepolicy目录下的文件进行逐一解析说明。
打开external\sepolicy目录,我们会发现里面有很多.te文件,这些te文件就是我们定义的策略文件,除了策略文件之外,还有很多没有后缀的,这些没有后缀的文件就是专门定义策略语句元素的。由于所有的te文件中的规则语句都是基于这些语句元素组成的,这里我们先来看下这些定义性文件:
1、定义性文件
users
该文件中定义了SElinux中唯一的用户u:
user u roles { r } level s0 range s0 - mls_systemhigh;
roles
该文件定义了SElinux中唯一的角色r:
role r;
role r types domain;
security_classes
该文件定义了所有通用客体类别:
# FLASK
#
# Define the security object classes
#
# Classes marked as userspace are classes
# for userspace object managers
class security
class process
class system
class capability
....
attributes
该文件定义了所有SContext中的通用type:
######################################
# Attribute declarations
#
# All types used for devices.
attribute dev_type;
# All types used for processes.
attribute domain;
# All types used for filesystems.
attribute fs_type;
....
access_vectors
该文件定义了资源的所有通用许可:
#
# Define common prefixes for access vectors
#
# common common_name { permission_name ... }
#
# Define a common prefix for file access vectors.
#
common file
{
ioctl
read
write
create
getattr
setattr
lock
relabelfrom
relabelto
append
unlink
link
rename
execute
swapon
quotaon
mounton
}
.....
file.te
该文件自定义了file_contexts中的所有文件类型的type:
# Filesystem types
type labeledfs, fs_type;
type pipefs, fs_type;
type sockfs, fs_type;
type rootfs, fs_type;
type proc, fs_type;
....
device.te
该文件自定义了file_contexts中的所有设备节点的type:
# Device types
type device, dev_type, fs_type;
type alarm_device, dev_type, mlstrustedobject;
type adb_device, dev_type;
file_contexts
....
该文件定义了所有文件资源的SContext:
#/##########################################
# Root
/ u:object_r:rootfs:s0
# Data files
/adb_keys u:object_r:adb_keys_file:s0
/default\.prop u:object_r:rootfs:s0
/fstab\..* u:object_r:rootfs:s0
/init\..* u:object_r:rootfs:s0
/res(/.*)? u:object_r:rootfs:s0
/ueventd\..* u:object_r:rootfs:s0
....
genfs_contexts
定义了虚拟文件的SContext:
# Label inodes with the fs label.
genfscon rootfs / u:object_r:rootfs:s0
# proc labeling can be further refined (longest matching prefix).
genfscon proc / u:object_r:proc:s0
genfscon proc /net u:object_r:proc_net:s0
....
fs_use
定义了所有文件系统类型的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;
....
service.te
定义了所有service_contexts中SContext的type:
type bluetooth_service, service_manager_type;
type default_android_service, service_manager_type;
type drmserver_service, service_manager_type;
....
service_contexts
定义了所有所有系统service的SContext:
accessibility u:object_r:accessibility_service:s0
account u:object_r:account_service:s0
activity u:object_r:activity_service:s0
alarm u:object_r:alarm_service:s0
....
mac_permissions.xml
与seapp_contexts一起负责为接下来安装的不同类型的app添加SContext。
<?xml version="1.0" encoding="utf-8"?>
<policy>
....
<!-- Platform dev key in AOSP -->
<signer signature="@PLATFORM" >
<seinfo value="platform" />
</signer>
<!-- All other keys -->
<default>
<seinfo value="default" />
</default>
</policy>
seapp_contexts
与mac_permissions.xml一起负责为接下来安装的不同类型的app添加SContext。
isSystemServer=true domain=system_server
user=system seinfo=platform domain=system_app type=system_app_data_file
user=bluetooth seinfo=platform domain=bluetooth type=bluetooth_data_file
user=nfc seinfo=platform domain=nfc type=nfc_data_file
....
2、其他te文件
剩余的.te文件中主要是各个进程的具体策略控制。这里我们拿recovery.te来举例说明。
recovery.te
# recovery console (used in recovery init.rc for /sbin/recovery)
# Declare the domain unconditionally so we can always reference it
# in neverallow rules.
type recovery, domain;
# But the allow rules are only included in the recovery policy.
# Otherwise recovery is only allowed the domain rules.
recovery_only(`
allow recovery self:capability { chown dac_override fowner fsetid setfcap setuid setgid sys_admin sys_tty_config };
# Set security contexts on files that are not known to the loaded policy.
allow recovery self:capability2 mac_admin;
# Run helpers from / or /system without changing domain.
allow recovery rootfs:file execute_no_trans;
allow recovery system_file:file execute_no_trans;
.....
allow recovery kernel:process setsched;
')
....
neverallow recovery data_file_type:file { no_w_file_perms no_x_file_perms };
neverallow recovery data_file_type:dir no_w_dir_perms;
这里定义了有关recovery的所有策略控制。
首先,文件开头定义了进程域名recovery,继承自domain,说明这里新定义的recovery域为进程域。接下来在recovery_only中制定了很多策略控制。
如:allow recovery system_file:file execute_no_trans;表示允许SContext标志为recovery的进程不可传递域地去执行SContext为system_file的文件。
最后还有neverallow检查语句,
如:neverallow recovery data_file_type:dir no_w_dir_perms;表示不允许SContext标志为recovery的进程去no_w_dir_perms SContext为data_file_type的目录。
五、如何配置SElinux
在支持SElinux的Android版本中,有关selinux策略文件有两处,一个是google原生的,另一个是产品平台配置的,他们分别对应如下目录:
google原生目录:s912/external/sepolicy
平台配置目录:s912/device/amlogic/common/sepolicy
在编译时, 系统会以合并的方式,将平台配置目录下的policy 附加到Google 原生的policy 上,而非替换。一般情况下,不建议修改google原生目录下的策略控制。接下来看下如何配置平台的selinux。
找到平台下的BoardConfig.mk,其相关变量配置就是BOARD_SEPOLICY_DIRS,目的就是指定平台sepolicy的目录。
BoardConfig.mk中直接包含了sepolicy的mkfile文件:
include device/amlogic/common/sepolicy.mk
打开该sepolicy.mk文件可以看到BOARD_SEPOLICY_DIRS变量的配置:
BOARD_SEPOLICY_DIRS := \
device/amlogic/common/sepolicy
六、SElinux调试方法
1、selinux的编译
首先我们关注下selinux的编译,大家知道编译整个Android工程是个很耗时的工作。为了避免耗时,在我们修改或者添加了selinux策略之后,建议先独自对sepolicy模块进行一次编译,如果通过了,然后再进行整个Android的编译。具体指令如下:
如:mmm external/sepolicy
2、如何快速确认是selinux引起?
目前所有的SELinux check 失败,在kernel log 或者android log(L版本后)中都有对应的" avc: denied"的LOG 与之对应。举例如下:
<5>[ 17.285600].(0)[503:idmap]type=1400 audit(1356999072.320:202): avc: denied { create } for pid=503 comm="idmap" name="overlays.list" scontext=u:r:zygote:s0 tcontext=u:object_r:resource_cache_data_file:s0 tclass=file
即表明idmap 这个process, 使用zygote 的source context, 访问/data/resource_cache 目录,并创建文件时,被SELinux 拒绝访问。
但反过来,有此LOG,并非就会直接失败,还需要确认当时SELinux 的模式, 是enforcing mode 还是 permissve mode.这里需要提到的是selinux有3中模式:permissive、enforcing和disabled。
-
enforcing:强制模式,代表 SELinux 运作中,且已经正确的开始限制 domain/type 了;
-
permissive:宽容模式:代表 SELinux 运作中,不过仅会有警告讯息并不会实际限制 domain/type 的存取。这种模式可以运来作为 SELinux 的 debug 之用;
-
disabled:关闭,SELinux 并没有实际运作。
如果问题容易复现,我们可以先将SELinux 模式调整到Permissive mode,然后再测试确认是否与SELinux 约束相关.
指令如下:
查看selinux当前模式:
[root@python bin]# getenforce
Permissive
更改当前的SELINUX值 ,后面可以跟 enforcing,permissive 或者 1, 0。
[root@python bin]# setenforce permissive
[root@python bin]# setenforce enforcing
3、修改/添加selinux策略
首先, 务必确认对应进程访问系统资源是否正常, 是否有必要?如果本身是异常非法访问,那么就要自行消除访问。
其次,如果确认访问是必要,并且正常的,那么就要对对应的process/domain 增加新的policy.
具体步骤大致如下:
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, 而无法知道你操作的真实意图,有可能出现权限放大问题。
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 版本为例)
*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/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;
七、案例分析
案例一、OTA升级过程中出现/system/etc/ppp/ip-up-vpn无法添加scontext
【问题现象】
制作好的差分包在升级过程中出现如下错误而导致升级失败,且重启后一直处于recovery模式下:
Symlinks and permissions...
ApplyParsedPerms: lsetfilecon of /system/etc/ppp/ip-up-vpn to u:ppp_system_file:s0 failed:Permission denied
set_metadata:some changes failed
E:Error in /udisk/update.zip
(Status 7)
该问题与问题一的提示信息基本一致,为何还是将本问题摘出来?这是因为他们的改动方案有所不同。
【问题分析】
出现上述错误后,根据提示信息可以确定升级包校验以及系统校验已经完成。这里是由于recovery中涉及selinux方面在向/system/etc/ppp/ip-up-vpn文件添加"u: ppp_system_file:s0"上下文(scontext)时因权限问题被拒绝了。
【解决方案】
方案1、3同问题一。
方案2、将META-INF\com\google\android\updater-script中的下列条目删除:
set_metadata_recursive("/system/etc/ppp ", "uid", 0, "gid", 0, "dmode", 0755, "fmode", 0555, "capabilities", 0x0, "selabel", "u:object_r:ppp_system_file:s0");
方案4、根据方案2中所删除的额条目中的function可以看出,该条目目的是要在system/etc/ppp目录下进行递归加scontext,但不知为何没有生效。由于system/etc/ppp目录下只有ip-up-vpn一个文件,该方案仿照问题一中方案4按照直接操作ip-up-vpn文件的思路进行添加修改,具体修改如下:
a、ip-up-vpn也是可执行文件,首先定义出该文件的selinux权限规则:
在device/amlogic/common/sepolicy目录下创建ip-up-vpn.te文件,并添加如下内容:
type ip-up-vpn, domain;
type ip-up-vpn_exec, exec_type, file_type;
init_daemon_domain(ip-up-vpn)
# Third line is important
allow ip-up-vpn input_device:chr_file rw_file_perms;
allow ip-up-vpn ppp_exec:file { execute_no_trans execute getattr read open };
allow ip-up-vpn ip-up-vpn_exec:file { entrypoint read setattr execute };
并更改其传统linux权限为777:
chmod 777 ip-up-vpn.te
b、在file_contexts中定义ip-up-vpn上下文属性(scontext):
/system/etc/ppp/ip-up-vpn u:object_r:ip-up-vpn_exec:s0
c、在recovery.te中添加操控ip-up-vpn的权限:
allow recovery ip-up-vpn_exec:file {create_file_perms relabelfrom relabelto create write setattr};
【结果确认】updater-script中该条目通过selinux操作,ota差分升级成功。
案例二、recovery删除data目录下的文件
在recover升级的时候,我们有个需要从服务器上下载升级包,然后放在data/download,这部分工作是放在一个systemapp中完成的。
然后重启进入recoveyr模式,在recovery升级完之后,我们需要在recovery中删除这个文件,这部分是在recovery中完成。
功能很简单,但是在android6.0上碰到selinux的问题。
我们先来看recovery.te中是不允许recovery操作data下面的目录,也就是下面这个neverallow原则
# Recovery should never touch /data.
#
# In particular, if /data is encrypted, it is not accessible
# to recovery anyway.
#
# For now, we only enforce write/execute restrictions, as domain.te
# contains a number of read-only rules that apply to all
# domains, including recovery.
#
# TODO: tighten this up further.
neverallow recovery data_file_type:file { no_w_file_perms no_x_file_perms };
neverallow recovery data_file_type:dir no_w_dir_perms;
我们再来看下system_data_file在file_contexts.te中的定义
/data(/.*)? u:object_r:system_data_file:s0
而在file.te定义了system_data_file文件属于data_file_type类型,因此recovery也是不能操作data下面的文件
[html] view plain copy 在CODE上查看代码片派生到我的代码片
./file.te:56:type system_data_file, file_type, data_file_type;
在我们可以自己定义自己的file类型,我们可以定义data/download属于download_data_file类型
/data/download(/.*)? u:object_r:download_data_file:s0
然后在file.te中定义download_data_file类型, 注意是只属于file_type类型的。
type download_data_file, file_type;
然后在recovery.te中增加对download_data_file的权限
allow recovery download_data_file:dir { write search remove_name };
allow recovery download_data_file:file { read getattr unlink };
另外我们还需在一个systemapp中先下载升级包,所以需要在system_app.te中增加对如下权限:
allow system_app download_data_file:dir { search write add_name getattr remove_name };
allow system_app download_data_file:file { create read write open getattr unlink };
但是最后还是失败了,为什么呢,因为一开始没有data/download这个目录,而是我们再app中自己下载的时候创建的目录,所以是system_data_file类型的。那么我们就需要在一开始就有data/download目录,所以在init.rc中添加如下代码:
mkdir /data/download 0771 system system
最后我们还需要在uncrypt.te中增加如下,因为data目录有可能需要进行加密处理。
allow uncrypt download_data_file:dir { search getattr };
allow uncrypt download_data_file:file { getattr read open };
八、常用指令
SELinux 是个经过安全强化的Linux操作系统,实际上,基本上原来的运用软件没有必要修改就能在它上面运行。真正做了特别修改的RPM包只要50多个。像文件系统EXT3都是经过了扩展。对于一些原有的命令也进行了扩展,另外还增加了一些新的命令,接下来我们就来看看这些命令。
1、文件操作
1)ls命令
在命令后加个 -Z 或者加 –context
[root@python azureus]# ls -Z
-rwxr-xr-x fu fu user_u:object_r:user_home_t azureus
-rw-r--r-- fu fu user_u:object_r:user_home_t Azureus2.jar+
-rw-r--r-- fu fu user_u:object_r:user_home_t Azureus.png
2)chcon
更改文件的标签
[root@python tmp]# ls --context test.txt
-rw-r--r-- root root root:object_r:staff_tmp_t test.txt
[root@python tmp]# chcon -t etc_t test.txt
[root@python tmp]# ls -lZ test.txt
-rw-r--r-- root root root:object_r:etc_t test.txt
3)restorecon
当这个文件在策略里有定义是,可以恢复原来的 文件标签。
4)setfiles
跟chcon一样可以更改一部分文件的标签,不需要对整个文件系统重新设定标签。
5)fixfiles
一般是对整个文件系统的, 后面一般跟 relabel,对整个系统 relabel后,一般我们都重新启动。如果,在根目录下有.autorelabel空文件的话,每次重新启动时都调用 fixfiles relabel
6)star
就是tar在SELinux下的互换命令,能把文件的标签也一起备份起来。
7)cp
可以跟 -Z, --context=CONTEXT 在拷贝的时候指定目的地文件的security context
8)find
可以跟 –context 查特定的type的文件。
例子:
find /home/fu/ --context fu:fu_r:amule_t -exec ls -Z {} \:
9)run_init
在sysadm_t里手动启动一些如Apache之类的程序,也可以让它正常进行,domain迁移。
2、进程domain的确认
程序现在在那个domain里运行,我们可以在ps 命令后加 -Z
[root@python /]# ps -eZ
LABEL PID TTY TIME CMD
system_u:system_r:init_t 1 ? 00:00:00 init
system_u:system_r:kernel_t 2 ? 00:00:00 ksoftirqd/0
system_u:system_r:kernel_t 3 ? 00:00:00 watchdog/0
3、ROLE的确认和变更
命令id能用来确认自己的 security context
[root@python ~]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:staff_r:staff_t
这里,虽然是ROOT用户,但也只是在一般的ROLE和staff_t里运行,如果在enforcing模式下,这时的ROOT对于系统管理工作来说什么也干不了。
[root@python ~]# newrole -r sysadm_r
Authenticating root.
口令:
[root@python ~]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:sysadm_r:sysadm_t
4、模式切换
1)getenforce
得到当前的SELINUX值
[root@python bin]# getenforce
Permissive
2)setenforce
更改当前的SELINUX值 ,后面可以跟 enforcing,permissive 或者 1, 0。
[root@python bin]# setenforce permissive
3)sestatus
显示当前的 SELinux的信息
[root@python bin]# sestatus -v
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 20
Policy from config file: refpolicy
Process contexts:
Current context: user_u:user_r:user_t
Init context: system_u:system_r:init_t
/sbin/mingetty system_u:system_r:getty_t
/usr/sbin/sshd system_u:system_r:sshd_t
File contexts:
Controlling term: user_u:object_r:user_devpts_t
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/bash system_u:object_r:shell_exec_t
/bin/login system_u:object_r:login_exec_t
/bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
/sbin/agetty system_u:object_r:getty_exec_t
/sbin/init system_u:object_r:init_exec_t
/sbin/mingetty system_u:object_r:getty_exec_t
5、其他重要命令
1)Audit2allow
很重要的一个以python写的命令,主要用来处理日志,把日志中的违反策略的动作的记录,转换成 access vector,对开发安全策略非常有用。在refpolicy里,它的功能比以前有了很大的扩展。
[root@python log]# cat dmesg | audit2allow -m local > local.te
2)checkmodule
编译模块
[root@python log]# checkmodule -m -o local.mod local.te
checkmodule: loading policy configuration from local.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 5) to local.mod
3)semodule_package
创建新的模块
[root@python log]# semodule_package -o local.pp -m local.mod
4)semodule
可以显示,加载,删除 模块
加载的例子:
[root@python log]# semodule -i local.pp
5)semanage
这是一个功能强大的策略管理工具,有了它即使没有策略的源代码,也是可以管理安全策略的。因为我主要是介绍用源代码来修改策略的,详细用法大家可以参考它的man页。
九、参考文献
1. Security-Enhanced Linux in Android
https://source.android.com/security/selinux/index.html
2. 深入理解SELinux SEAndroid
http://blog.csdn.net/innost/article/details/19299937
3.SElinux详解.pdf
4.类型强制(TE编写规则)
http://blog.csdn.net/myarrow/article/details/10105961