SELinux策略语言中没有预定义类型,所有的类型来自于声明。故类型在使用前都必须被明确的声明,默认的,所有类型都以xxx_t的形式来声明。声明之后就可以在TE规则、安全上下文和其他策略语句中使用了。
格式:type name_t [alias 别名集合({}+空格分隔)] [属性集合(,分隔)];
type http_t;
type httpd_user_content_t;
SELinux策略语言中的属性是类型的属性或类型的性质,它可以表示一组类型(attribute = 一组type)。
计算机OS中的资源数不胜数、成千上万,如果要对这么多资源分门别类定义不同的类型进行SELinux要实现的访问管理(MAC),那要定义的类型也是极多的。一个大型的,复杂的策略可能包括上万个代表系统上不同资源的类型,例如:Fedora Core 4(FC4)的targeted策略相对较小,但也声明了超过800个类型。当定义新类型时,给其allow权限是一个单调且容易出错的过程。
因为上述这种情况,属性出现了,如果说类型是资源的分类,那么属性就是类型的分类。赋予一个属性的访问权限就 等于 赋予访问者所有带有这种属性的类型的资源的访问权限。这代表着,当新增类型时,不需要手动添加allow规则,只需将属性和类型关联即可。
属性与类型共享同一个命名空间,所以二者不可以同名,为了区分,属性以xxx_type形式被声明。
//属性声明
attribute attr_type;
attribute file_type;
allow backup_t file_type :file read;
//赋予backup_t类型的进程 访问 具有file_type属性的类型的文件 读权限。
1个类型可拥有的属性数量没有限制,即一个类型可拥有多个属性。关联操作有2种,格式如下。
//关联操作1
//声明type_t类型的同时,关联属性attr_type
type type_t,attr_type;
//关联操作2
//操作2的特点在于,类型的声明和关联是分开的,这意味着声明和关联两个操作可被模块化设计(各放在一个源文件中)
//,利于设计、管理,增强了语言的灵活性。
type type_t;
typeattribute type_t attr_type,content_type;//type_t关联了2个属性
用于模块更新前后改名的兼容性
# 这两条语句等同于
type mozilla_t, domain;
typealias mozilla_t alias netscape_t;
#下面这一条语句
type mozilla_t alias netscape_t, domain;
使用宏定义能够减去反复撰写重复性代码的劳动。常见的有,
// Linux Android源码位置system/sepolicy/prebuilts/api/28.0/public/te_macros
set_prop(sourcedoamin, targetproperty),
get_prop(sourcedoamin, targetproperty)
SELinux的策略的规则可分为2类
AV规则就是按照对客体类别的访问许可指定其具体含义的规则,SELinux策略语言目前支持四类AV规则:
虽然这些规则的用途不一样,但它们的基本语法是一样的,每个规则都要包含下面五个元素:
一个简单的AV规则有上述这些源类型,目标类型,客体类别和许可,例如
allow user_t bin_t : file execute;
//这个allow规则的源类型为user_t,目标类型为bin_t,客体类别file,许可execute,
//这个规则可以解读为"允许user_t类型的进程执行类型为bin_t的文件"
在内核中,所有AV规则都是通过一组“源类型+目标类型+客体类别”组成的字段作为唯一性标识,这个组合被称为秘钥。
秘钥被当作哈希表使用,缓存在policy数据结构中,AV规则依靠秘钥存储和检索。存储用到秘钥是因为多条相同秘钥的规则通过checkpolicy进行组合,编译后只剩下一条拥有多条许可的规则。所有的AV都按照这种方式进行累加。
allow src_t obj_t : file read;
allow src_t obj_t : file execute;
//Key :"src_t obj_t file"
AV规则中所有能使用类型的地方都能用属性,源类型、目标类型这两者都可以用属性表示,并且用了属性之后,一条规则语句往往在编译后会被扩展成多条规则,十分方便。并且在编译后,每一个与属性关联的类型都有一个独立的秘钥。
AV规则中可使用多类型与多属性,属性和类型支持混合组成源类型与目标类型,使用{}+空格来表示。
allow {usr_t domain} {adbd_type file_t} : file execute;
// 源类型 usr_t domain 目标类型 adbd_type file_t
在规则语句中,self可理解为是该语句中的源类型的别名,用作目标类型,即目标类型 == 源类型。
# 这两条规则
allow user_t user_t : process signal;
allow staff_t staff_t : process signal;
#等于下面这一条规则
allow {user_t staff_t} self : process signal;
"-"类型否定操作符可用于移除一个属性中的某个类型。使用之后那么编译时就会去除掉那个被否定的类型,不会生成它的秘钥。
allow domain {exec_type -sbin_t} : file execute;
allow domain {-sbin_t exec_type} : file execute;
AV规则中可包括类别和许可列表,使用“ {} + 空格 ”表示,这意味这列表中的所有许可对所有类别都有效。
allow src_t bin_t : {file dir} {read getattr} //这会解释成4条规则
//如果许可对类别列表中的某项无效,那么规则也会无效
allow src_t bin_t : {file dir} {read search getattr} //search许可对file类别无效
通配符表示所有许可,类别列表中有与许可无效的成员也不影响其他许可的有效性。猜测是因为通配的原因,在编译的时候首先被分成n条语句,除了无效许可那条外其他都有效。
allow usr_t bin_t : { file dir } * ;
补算符表示 包含所有许可,除了被~修饰的许可。
allow usr_t bin_t : { file dir } ~{ write setattr ioctl } ;
类型规则在创建客体或在运行过程中重新标记时指定其默认类型,它仅提供一个新的默认类型标记。在策略语言中定义了两个类型规则:
类型规则没有allow访问权,相反,它们指定了客体创建和重新标记事件想要的默认标记策略。
与AV规则一样,每条类型规则有不同的用途和语义,但它们的语法都是通用的,每条类型规则都具有下列五项元素:
规则名称:type_transition或type_change
。
源类型:创建或拥有进程的类型
目标类型:包含新的或重新标记的客体的客体类型
客体类别:新创建的或重新标记的客体的类别
默认类型:新创建的或重新标记的客体的单个默认类型
规则名称 类型集 类型集:类别集 单个默认类型;
顾名思义,类型转换规则用于触发某种条件时,对客体类型进行转换的一个规则。它指定了一个默认类型
目前有两种格式的type_transition语句
使用type_change规则为重新标记客体指定默认的类型,它们用于SELinux敏感的程序如login和sshd。
与type_transition不同的是:type_change规则的影响不会在内核中生效,而是依赖于用户空间应用程序,如login或sshd
SELinux将策略分为两部分
private 平台私有策略:私有策略定义在/system/sepolicy/private下,private下的type和attribute对non-platform policy作者是不可见的。
public 平台公有策略:平台公有策略全部定义在/system/sepolicy/public下,public下的type和attribute可以被被导出,供以non-platform中的策略所使用。
Android8.0的SElinux策略是由/system和/vendor中的策略合并而来的。具体构建的逻辑声明在/android/stem/sepolicy/Android.mk中。
Location | Contains |
---|---|
system/sepolicy/public | 平台策略 |
system/sepolicy/private | 平台策略 |
system/sepolicy/vendor | 平台对vendor相关的定义 |
BOARD_SEPOLICY_DIRS vendor | 策略 |
编译器采用这种逻辑将平台和非平台策略组件分别打包到vendor和system的镜像中去。 |
报错的解决方式有两种,手动解决和命令自动解决。
dell@dell:~$ vim allow.txt //将出错的log编辑成文件
如:audit: type=1400 audit(9466.339:6): avc: denied { setattr } for pid=1 comm="init" name="sdd1" dev="tmpfs" ino=7522 scontext=u:r:init:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file permissive=0
dell@dell:~$ audit2allow -i allow.txt //使用audit2allow对其进行检查
#============= init ==============
allow init block_device:blk_file setattr; // 少了setattr属性
sepolicy的allow语句的格式如下
allow [source_type] [target_type]:[target_class] [action];
而系统在报avc denied的log时,会列出allow语句中的所有log属性,只要解读了这些语句,就能够手动增加allow规则,消除avc denied。
需要注意的是,source_type和target_type这两个参数位于scontext和tcontext安全上下文的type字段中。
举个例子:
avc: denied { read write } for name="sdd1" dev="tmpfs" ino=2089 scontext=u:r:shell:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file permissive=0
其中
action : { read write }
source_type : shell
target_type : block device
target_class: blk_file
故组成的sepolicy语句为:allow shell block_device:blk_file { read write };
Android8.0 SELinux详解
SELinux语法
解决avc-denied之设置SELinux策略