http://blog.csdn.net/innost/article/details/19299937
一 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权限。
显然，MAC比DAC在权限管理这一块要复杂，要严格，要细致得多。
那么，关于DAC和MAC，此处笔者总结了几个知识点：
Linux系统先做DAC检查。如果没有通过DAC权限检查，则操作直接失败。通过DAC检查之后，再做MAC权限检查。
SELinux中也有用户的概念，但它和Linux中原有的user概念不是同一个东西。什么意思呢？比如，Linux中的超级用户root在SELinux中可能就是一个没权限，没地位，打打酱油的”路人甲“。当然，这一切都由SELinux安全策略的制定者来决定。
2. SELinux Policy语言介绍
Linux中有两种东西，一种死的（Inactive），一种活的（Active）。死的东西就是文件（Linux哲学，万物皆文件。注意，万不可狭义解释为File），而活的东西就是进程。此处的“死”和“活”是一种比喻，映射到软件层面的意思是：进程能发起动作，例如它能打开文件并操作它。而文件只能被进程操作。
SELinux中，每种东西都会被赋予一个安全属性，官方说法叫Security Context。Security Context（以后用SContext表示）是一个字符串，主要由三部分组成。例如SEAndroid中，进程的SContext可通过ps -Z命令查看，如图1所示：
LABEL USER PID PPID VSIZE RSS WCHAN PC NAME
u:r:mediacodec:s0 mediacodec 2884 1 25200 6496 binder_thr b0d87968 S media.codec
u:r:mediadrmserver:s0 media 2885 1 25628 7476 binder_thr b40de968 S /system/bin/mediadrmserver
u:r:mediaextractor:s0 mediaex 2886 1 47532 7400 binder_thr b1446968 S media.extractor
u:r:mediaserver:s0 media 2887 1 139856 23384 binder_thr a4865968 S /system/bin/mediaserver
u:r:netd:s0 root 2888 1 27560 3440 binder_thr b0aee968 S /system/bin/netd
u:r:remotedisplay:s0 remotedisplay 2890 1 25548 7432 binder_thr a824b968 S /system/bin/remotedisplay
图1中最左边的那一列是进程的SContext，以第一个进程/system/bin/remotedisplay的SContext为例，其值为u:r:remotedisplay: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来查看，如图2所示
图2中，倒数第二列所示为Nexus 7根目录下几个文件和目录的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的级别。
根据SELinux规范，完整的SContext字符串为：
user:role:type[:range]
注意，方括号中的内容表示可选项。s0属于range中的一部分。下文再详细介绍range所代表的Security Level相关的知识。
看，SContext的核心其实是前三个部分：user:role:type。
刚才说了，MAC基本管理单位是TEAC（Type Enforcement Accesc Control），然后是高一级别的Role Based Accesc Control。RBAC是基于TE的，而TE也是SELinux中最主要的部分。
下面来看看TE。
2.1 TE介绍
在例子1中，大家已经见过TE的allow语句了，再来细致研究下它：
[例子2]
allow netd proc:file write
这条语句的语法为：
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
我们直接来看几个实例：
[例子3]
//SEAndroid中的安全策略文件policy.conf
#允许zygote域中的进程向init type的进程（Object Class为process）发送sigchld信号
allow zygote init:process sigchld;
#允许zygote域中的进程search或getattr类型为appdomain的目录。注意，多个perm_set
#可用{}括起来
allow zygote appdomain:dir { getattr search };
#来个复杂点的：
#source_type为unconfineddomain target_type为一组type，由
#{ fs_type dev_type file_type }构成。object_class也包含两个，为{ chr_file file }
#perm_set语法比较奇特，前面有一个~号。它表示除了{entrypoint relabelto}之外，{chr_file #file}这两个object_class所拥有的其他操作
allow unconfineddomain {fs_type dev_type file_type}:{ chr_file file } \
~{entrypoint relabelto};
#特殊符号除了~外，还有-号和*号，其中：
# 1）：-号表示去除某项内容。
# 2）：*号表示所有内容。
#下面这条语句中，source_type为属于appdomain，但不属于unconfinedomain的进程。
#而 *表示所有和capability2相关的权限
#neverallow：表示绝不允许。
neverallow { appdomain -unconfineddomain } self:capability2 *;
特别注意，前面曾提到说权限必须显示声明，没有声明的话默认就没有权限。那neverallow语句就没必要存在了。因为”无权限“是不需要声明的。确实如此，neverallow语句的作用只是在生成安全策略文件时进行检查，判断是否有违反neverallow语句的allow语句
下面我们来看上述allow语句中所涉及到的object class和perm set。
（1） Object class和Perm Set
Object class很难用语言说清楚它到底是怎么定义的，所以笔者也不废话，直接告诉大家常见的Object class有哪些。见下面的SEPolicy示例：
[system/sepolicy/security_classes示例]
.......
#此文件定义了Android平台中支持的Object class
#根据SELinux规范，Object Class类型由class关键字申明
# file-related classes
class filesystem
class file #代表普通文件
class dir #代表目录
class fd #代表文件描述符
class lnk_file #代表链接文件
class chr_file #代表字符设备文件
......
# Service manager
class service_manager # userspace
#Android平台特有的属性服务。注意其后的userspace这个词
class property_service # userspace和用户空间中的SELinux权限检查有关，下文再解释
上述示例展示了SEAndroid中Object Class的定义，其中：
Object Class需要通过class语句申明。这些申明一般放在一个叫security_class的文件中。
另外，这些class和kernel中相关模块紧密结合。
再来看Perm set。Perm set指得是某种Object class所拥有的操作。以file这种Object class而言，其拥有的Perm set就包括read，write，open，create,execute等。
和Object class一样，SELinux或SEAndroid所支持的Perm set也需要声明，来看下面的例子：
[external/sepolicy/access_vectors]
#SELinux规范中，定义perm set有两种方式，一种是使用下面的common命令
#其格式为：common common_name { permission_name ... } common定义的perm set能
#被另外一种perm set命令class所继承
#以下是Android平台中，file对应的权限（perm set）。其大部分权限读者能猜出是干什么的。
#有一些权限需要结合文后的参考文献来学习
class service_manager
{
add
find
list
}
（2） type，attribute和allow等
现在再来看type的定义，和type相关的命令主要有三个，如下面的例子所示：
[external/sepolicy相关文件]
#type命令的完整格式为：type type_id [alias alias_id,] [attribute_id]
#其中，方括号中的内容为可选。alias指定了type的别名，可以指定多个别名。
#下面这个例子定义了一个名为shell的type，它和一个名为domain的属性（attribute）关联
type shell, domain; #本例来自shell.te，注意，可以关联多个attribute
#属性由attribute关键字定义，如attributes文件中定义的SEAndroid使用的属性有：
attribute domain
attribute file_type
#可以在定义type的时候，直接将其和某个attribute关联，也可以单独通过
#typeattribue将某个type和某个或多个attribute关联起来，如下面这个例子
#将前面定义的system类型和mlstrustedsubject属性关联了起来
typeattribute system mlstrustedsubject
特别注意：对初学者而言，attribute和type的关系最难理解，因为“attribute”这个关键词实在是没取好名字，很容易产生误解：
实际上，type和attribute位于同一个命名空间，即不能用type命令和attribute命令定义相同名字的东西。
其实，attribute真正的意思应该是类似type（或domain） group这样的概念。比如，将type A和attribute B关联起来，就是说type A属于group B中的一员。
使用attribute有什么好处呢？一般而言，系统会定义数十或数百个Type，每个Type都需要通过allow语句来设置相应的权限，这样我们的安全策略文件编起来就会非常麻烦。有了attribute之后呢，我们可以将这些Type与某个attribute关联起来，然后用一个allow语句，直接将source_type设置为这个attribute就可以了：
这也正是type和attribute位于同一命名空间的原因。
这种做法实际上只是减轻了TE文件编写者的烦恼，安全策略文件在编译时会将attribute拓展为其包含的type。如例子4所示：
[例子4]
#定义两个type，分别是A_t和B_t，它们都管理到attribute_test
type A_t attribute_test;
type B_t attribute_test;
#写一个allow语句，直接针对attribute_test
allow attribute_test C_t:file {read write};
#上面这个allow语句在编译后的安全策略文件中会被如下两条语句替代：
allow A_t C_t:file {read write};
allow B_t C_t:file {read write};
前面讲过，TE的完整格式为：
rule_name source_type target_type : class perm_set
所以，attribute可以出现在source_type中，也可以出现在target_type中。
提示：一般而言，定义type的时候，都会在名字后添加一个_t后缀，例如type system_t。而定义attribute的时候不会添加任何后缀。但是Android平台没使用这个约定俗成的做法。不过没关系，SEAndroid中定义的attribute都在external/sepolicy/attribute这个文件中，如果分不清是type还是attribute，则可以查看这个文件中定义了哪些attribute。
最后我们来看看TE中的rule_name，一共有四种：
allow：赋予某项权限。
allowaudit：audit含义就是记录某项操作。默认情况下是SELinux只记录那些权限检查失败的操作。allowaudit则使得权限检查成功的操作也被记录。注意，allowaudit只是允许记录，它和赋予权限没关系。赋予权限必须且只能使用allow语句。dontaudit：对那些权限检查失败的操作不做记录。neverallow：前面讲过，用来检查安全策略文件中是否有违反该项规则的allow语句。如例子5所示：
[例子5]
#来自external/sepolicy/netd.te文件
#永远不允许netd域中的进程 读写 dev_type类型的 块设备文件（Object class为blk_file）
neverallow netd dev_type:blk_file { read write }
3） RBAC和constrain
绝大多数情况下，SELinux的安全配置策略需要我们编写各种各样的xx.te文件。由前文可知，.te文件内部应该包含包含了各种allow，type等语句了。这些都是TEAC，属于SELinux MAC中的核心组成部分。
在TEAC之上，SELiunx还有一种基于Role的安全策略，也就是RBAC。RBAC到底是如何实施相关的权限控制呢？我们先来看SEAndroid中Role和User的定义。
[external/sepolicy/roles]
#Android中只定义了一个role，名字就是r
role r;
#将上面定义的r和attribute domain关联起来
role r types domain;
再来看user的定义。
[external/sepolicy/users]
#支持MLS的user定义格式为：
#user seuser_id roles role_id level mls_level range mls_range;
#不支持MLS user定义格式为：
#user seuser_id roles role_id;
#SEAndroid使用了支持MLS的格式。下面定义的这个user u，将和role r关联。
#注意，一个user可以和多个role关联。
#level之后的是该user具有的安全级别。s0为最低级，也就是默认的级别，mls_systemHigh
#为u所能获得的最高安全级别（security level）。此处暂且不表MLS
user u roles { r } level s0 range s0 - mls_systemhigh;
那么，Roles和User中有什么样的权限控制呢？
1）首先，我们应该允许从一个role切换（SELinux用Transition表达切换之意）到另外一个role，例如：
#注意，关键字也是allow，但它和前面TE中的allow实际上不是一种东西
#下面这个allow允许from_role_id切换到to_role_id
allow from_role_id to_role_id;
2) 角色之间的关系。SELinux中，Role和Role之间的关系和公司中的管理人员的层级关系类似，例如：
#dominance语句属于deprecated语句，MLS中有新的定义层级相关的语句。不过此处要介绍的是
#selinux中的层级关系
#下面这句话表示super_r dominate（统治，关键词dom） sysadm_r和secadm_r这两个角色
#反过来说，sysadm_r和secadm_r dominate by (被统治，关键词 domby) super_r
#从type的角度来看，super_r将自动继承sysadm_r和secadm_r所关联的type（或attribute）
dominance { role super_r {role sysadm_r; role secadm_r; }
3）其他内容，由于SEAndroid没有使用，此处不表。读者可阅读后面的参考文献。
话说回来，怎么实现基于Role或User的权限控制呢？SELinux提供了一个新的关键词，叫constrain，来看下面这个例子：
关于constrain，再补充几个知识点：
SEAndroid中没有使用constrain，而是用了MLS中的mlsconstrain。所以下文将详细介绍它。
constrain是对TEAC的加强。因为TEAC仅针对Type或Domain，没有针对user和role的，所以constrain在TEAC的基础上，进一步加强了权限控制。在实际使用过程中，SELinux进行权限检查时，先检查TE是否满足条件，然后再检查constrain是否也满足条件。二者都通过了，权限才能满足。
关于RBAC和constrain，我们就介绍到此。
提示：笔者花了很长时间来理解RBAC和constrain到底是想要干什么。其实这玩意很简单。因为TE是Type Enforcement，没user和role毛事，而RBAC则可通过constrain语句来在user和role上再加一些限制。当然，constrain也可以对type进行限制。如此而已！
2.2 Labeling介绍
前面陆陆续续讲了些SELinux中最常见的东西。不过细心的人可能会问这样一个问题：这些SContext最开始是怎么赋给这些死的和活的东西的？Good Question！
提示：SELinux中，设置或分配SContext给进程或文件的工作叫Security Labeling，土语叫打标签
initial_sids：定义了LSM初始化时相关的信息。SID是SELinux中一个概念，全称是Security Identifier。SID其实类似SContext的key值。因为在实际运行时，如果老是去比较字符串（还记得吗，SContext是字符串）会严重影响效率。所以SELinux会用SID来匹配某个SContext。
initial_sid_context：为这些SID设置最初的SContext信息。
来看这两个文件的内容：
[external/sepolicy/initial_sids和initial_sid_context]
#先看initial_sids
sid kernel #sid是关键词，用于定义一个sid
sid security
sid unlabeled
sid fs
sid file
sid file_labels
sid init
......
#再来看initial_sid_context
sid kernel u:r:kernel:s0 #将initial_sids中定义的sid和初始的SContext关联起来
sid security u:object_r:kernel:s0
sid unlabeled u:object_r:unlabeled:s0
sid fs u:object_r:labeledfs:s0
sid file u:object_r:unlabeled:s0
sid file_labels u:object_r:unlabeled:s0
sid init u:object_r:unlabeled:s0
2） Domain/Type Transition和宏
SEAndroid中，init进程的SContext为u:r:init:s0，而init创建的子进程显然不会也不可能拥有和init进程一样的SContext（否则根据TE，这些子进程也就在MAC层面上有了和init一样的权限）。那么这些子进程的SContext是怎么被打上和其父进程不一样的SContext呢？
SELinux中，上述问题被称为Domain Transtition，即某个进程的Domain切换到一个更合适的Domain中去。Domain Transition也是需要我们在安全策略文件中来配置的，而且有相关的关键词，来看例子7。
[例子7-1]
#先要使用type_transition语句告诉SELinux
#type_transition的完整格式为：
# type_transition source_type target_type : class default_type;
#对Domain Transition而言有如下例子：
type_transition init_t apache_exec_t : process apache_t;
DT(domain transtition) 太麻烦了，不细看了
....................................................
2.3 Security Level和MLS
（1） Security Level
上文介绍的TE，RBAC基本满足了“平等社会”条件下的权限管理，但它无法反映现实社会中等级的概念。为此，SELinux又添加了一种新的权限管理方法，即Multi-Lever Security，多等级安全。多等级安全信息也被添加到SContext中。所以，在MLS启用的情况下（注意，你可以控制SELinux启用用MLS还是不启用MLS），完整的SContext由
MLS未启用前：user_u:role_r:type_t。
MLS启用后，user:role:type:sensitivity[:category,...]- sensitivity [:category,...]。
看，MLS启用后，SContext type后面的字段变得非常复杂，看着有些头晕（至少笔者初学它时是这样的）。下面马上来解释它。
[Security-level解析]
|-->low security level<--| - |-->high security level<--|
sensitivity[:category,...] - sensitivity [:category,...]
上述字符串由三部分组成：
low security level：表明当前SContext所对应的东西（活的或死的）的当前（也就是最小）安全级别。
连字符“-”，表示range
high security level：表明当前SContext所对应的东西（活的或死的）的最高可能获得的安全级别（英文叫clearance，不知道笔者的中文解释是否正确）。
2.4 编译安全策略文件
到此，SELinux Policy语言中的基本要素都讲解完毕，相信读者对着真实的策略文件再仔细研究下就能彻底搞明白。
不过，我们前面反复提到的安全策略文件到底是什么？我们前面看到的例子似乎都是文本文件，难道就它们是安全策略文件吗？
拿个例子说事，来看图6中Android的策略文件：
Android中，SELinux的安全策略文件如图6所示。这么多文件，如何处理呢？来看图7
左边一列代表安全配置的源文件。也即是大家在图6中看到的各种te文件，还有一些特殊的文件，例如前文提到的initial_sid，initial_sid_contexts，access_vectors、fs_use,genfs_contexts等。在这些文件中，我们要改的一般也是针对TE文件，其他文件由于和kernel内部的LSM等模块相关，所以除了厂家定制外，我们很难有机会去修改。
这些文件都是文本文件，它们会被组合到一起（图7中是用cat命令，不同平台处理方法不相同，但大致意思就是要把这些源文件的内容搞到一起去）。
搞到一起后的文件中有使用宏的地方，这时要利用m4命令对这些宏进行拓展。m4命令处理完后得到的文件叫policy.conf。前面我们也见过这个文件了，它是所有安全策略源文件的集合，宏也被替换。所以，读者可以通过policy.conf文件查看整个系统的安全配置情况，而不用到图6中那一堆文件中去找来找去的。
policy.conf文件最终要被checkpolicy命令处理。该命令要检查neverallow是否被违背，语法是否正确等。最后，checkpolicy会将policy.conf打包生成一个二进制文件。在SEAndroid中，该文件叫sepolicy，而在Linux发行版本上，一般叫policy.26等名字。26表示SELinux的版本号。
最后，我们再把这个sepolicy文件传递到kernel LSM中，整个安全策略配置就算完成
.......................................................................
总结：
sepolicy的重头工作是编译sepolicy安全策略文件。这个文件来源于众多的te文件，初始化相关的文件（initial_sid,initial_sid_context,users,roles,fs_context等）。
file_context：该文件记载了不同目录的初始化SContext，所以它和死货打标签有关。
seapp_context：和Android中的应用程序打标签有关。
property_contexts：和Android系统中的属性服务（property_service）有关，它为各种不同的属性打标签。
4 小试牛刀
下面，笔者将通过修改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，所以它将使用这个新的。
===========================================================================
1.2.1 How SELinux Works
Figure 1-1 depicts the operation of SELinux in a highly simplified fashion. SELinux works by associating each program or process with a sandbox known as a domain. Each domain is assigned a set of permissions sufficient to enable it to function properly but do nothing else. For instance, a domain is limited in the files it can access and the types of operations it can perform on those files. To enable specification of such permissions, each file is labeled with information called a security context. The definition of a domain spells out what operations it can perform on files having specific security contexts. A domain cannot access files having security contexts other than those for which it is explicitly granted access.
An SELinux facility known as type enforcement (TE) ensures that the rules governing domains are always observed. SELinux also has a secondary facility known as role-based access control (RBAC). RBAC limits user access to domains. For instance, some domains are defined to be accessible only to the system administrator, whereas other domains are defined to be publicly available to any user.
2.1 Linux and SELinux: Dueling Security Mechanisms?
As explained in the preceding chapter, Linux has its own system of discretionary access control (DAC). How does Linux DAC interoperate with the mandatory access control (MAC) provided by SELinux? Do we end up with dueling security mechanisms?
Fortunately, Linux DAC and SELinux MAC play well together. When making security decisions, SELinux first hands off the decision to Linux DAC. If DAC forbids an action, the action is not permitted. If, on the other hand, DAC permits an action, then SELinux performs its own authorization check, based on MAC. A requested action is allowed to occur only if both the Linux DAC and SELinux MAC authorizations are approved.
2.2 Security Contexts
simplify decision making, similar subjects can be grouped and similar objects
can be grouped
User identity
The user identity indicates the SELinux user account associated with a subject or object. In the case of a subject, the user identity gives the SELinux user account under which the process is running. In the case of an object, the user identity gives the user account that owns the object.
Role
Under SELinux, users are authorized to enter one or more roles, each of which defines a set of permissions a user can be granted. At a given time, a user can reside in only a single role. A user can transition from one authorized role to another by using the special command newrole. This command changes the user's SELinux role similar to the way the Linux su command changes a user's Linux identity. SELinux establishes a special role, sysadm_r, used for administering SELinux facilities.
Type
Types, which are also known as domains, divide subjects and objects into related groups. Types are the primary security attribute SELinux uses in making authorization decisions. They establish the sandboxes that constrain processes and prevent privilege escalation. Therefore, you can think of a type as naming a related sandbox.
2.4 Access Decisions |
The three access vectors have the following functions:
Allow
The allow access vector identifies operations that the subject is permitted to perform on the object. No log entry is made of the operation.
Auditallow (就是不允许)
The auditallow access vector causes a log entry to be made when the indicated operation is performed. Despite its name, it doesn't allow any operation; only the Allow vector does so.
Dontaudit（不允许，同时不记录到log）
The dontaudit access vector identifies operations that the subject is not permitted to perform on the object, but that don't cause the denial to be logged.
5.3 Anatomy of a Simple SELinux Policy Domain
Security context
The security context specifies the SELinux user, role, and type with which the directory or file is to be labeled.
5.3.2.1 The type line
The line:
type snort_etc_t, file_type, sysadmfile;
defines snort_etc_t as a type. The attributes file_type and sysadmfile mark this type as pertaining to file objects that can be accessed and modified by users associated with the sysadm_r (system administrator) role. Many such attributes are defined in the attrib.te file.
5.3.2.2 The allow lines
beginning with the keyword allow specify access vector rules authorizing operations on various object types. For instance, the line:
allow snort_t etc_t:file { getattr read };specifies that processes running in the snort_t domain can read and get the attributes of files labeled with the etc_t type. Notice the use of curly braces, { and }, to enclose the list