se 概念重复

http://blog.csdn.net/js_wawayu/article/details/52719817

基础知识

SEAndroid在架构和机制上与SELinux完全一样，考虑到移动设备的特点，所以移植到SEAndroid的只是SELinux的一个子集。
SEAndroid的安全检查覆盖了所有重要的方面包括了域转换、类型转换、进程相关操作、内核相关操作、文件目录相关操作、文件系统相关操作、对设备相关操作、对app相关操作、对网络相关操作、对IPC相关操作。
在有关SELinux的相关内容见10.112.25.156/mediawiki/index.php/SEAndroid

在SEAndroid中主要采用了两种强制访问方法：TE MLS

在SEAndroid中有关policy的相关源文件都在源码目录external/sepolicy中，
在Android.mk文件中描述了相关编译过程，
首先会使用m4预处理器将sepolicy中的所有相关文件整合成一个源文件plicy.conf，
然后通过checkpolicy 编译器将policy.conf策略源文件编译成sepolicy.24的二进制策略文件（24为策略版本号）。
checkpolicy编译器的所有源文件都在external/checkpolicy目录中，编译完成的二进制策略文件会在系统启动时被加载到内核中在权限检测时使用，
而在系统启动时为一些系统文件添加安全上下文则是依据另外两个文件file_contexts和seapp_contexts实现。

security level：第四列是专为MLS访问机制所添加的安全上下文的扩展部分，格式为sensitivity[:category list][- sensitivity[:category list]]，例如s0 - s15:c0.c1023，其中s0之后的内容可以不需要，冒号后面的内容是category，sensitivity和category组合一起声明了当前的安全级别(security level)，“-”号左右分别标识了安全级别的最低和最高，这一列的参数将在MLS约束检查时用到，“15”、“1023”表示了sensitivity和category的最大值，这一参数可在Android.mk中定义。

SEAndroid中关于安全上下文配置的核心文件主要是file_contexts文件、seapp_contexts文件和ocontexts文件。

1.初始SID标记

安全上下文在用户态通过字符串来描述，而在内核中使用context数据结构来表示它。
给每个context数据结构都分配一个u32 sid，该sid保存在描述内核数据结构的安全上下文中。
内核驱动使用sidtab哈希表来描述所有已经分配了sid的context数据结构，通过查询该哈希表即可得到一个安全上下文所对应的sid。
几乎所有sid的分配和注册都是在运行时完成的，但是在refpolicy中定义了27个“Initial SID”，用于在内核驱动初始化时、由init进程通过selinuxfs接口加载policy之前，描述相应内核设施的初始安全属性。
初始SID提供了一种特殊的默认标记行为，初始SID适用于两种环境：在系统初始化策略还没有载入前对一部分内核相关的客体进行标记，以及当客体的安全上下文无效或安全上下文丢失时使用。
初始sid的内容被定义在了initial_sids文件中，在ocontexts文件中同时声明了初始sid相应的安全上下文。

2.为文件系统和文件系统中的文件标记安全上下文

在SEAndroid中存在两种文件系统，
一种是常见的文件系统包括传统的、本地文件系统都是用来在磁盘上或可移动介质上存储数据（如ext3和XFS），和为了兼容其它操作系统的非本地文件系统（如iso9660和vfat），
另一种是存在于内存中被称为伪文件系统，它是用于内核和用户空间之间的通讯（如proc和sysfs），通过selinux库中提供的API函数完成。
文件系统的初始安全上下文的标记是在文件系统挂载时完成，另外普通文件系统上的文件在文件创建时就标记好了安全上下文并和文件一起存储在磁盘上，
而伪文件系统只在运行时才会为其中的文件标记安全上下文。

伪文件系统标记安全上下文是对该文件系统的所有inode节点进行安全上下文的标记，这些标记是最原始的标记，之后如有新的文件被创建并赋予了相应的安全上下文标记则将会执行覆盖操作保留最新的安全上下文。

对于文件系统的标记SEAndroid依据各文件系统的不同属性拥有不同的机制：
基于支持扩展属性的文件系统标记（即允许保存安全上下文这一扩展属性的文件系统）（fs_use_xattr）
这一类文件系统包括yaffs2、jffs2、ext2、ext3、ext4、xfs、btrfs，它们的一个共性是都支持在磁盘上永久保存安全上下文这一扩展属性信息。
它们都用同一个安全上下文u:object_r:labeledfs:s0被统一标记，这些都在ocontexts文件中被声明，使用fs_use_xattr语法实现。

另外对于这些有唯一且永久的节点号的传统文件系统来说，SEAndroid会用一个永久的标记映射来决定文件系统内的节点的安全上下文和文件系统本身的安全上下文，
这个永久的标记映射是由一个或多个配置文件组成，
在SEAndroid中就是file_contexts文件和seapp_contexts文件，这两个文件会和policy二进制文件一起构成整个SEAndroid的安全策略体系。

file_contexts文件对相应目录的使用正则表达式进行匹配，被匹配到的目录或文件都将被标记上相应的安全上下文，这个过程发生在文件系统标记完成之后执行。

基于任务的文件系统标记（fs_use_task）

使用基于任务的标记时，在SEAndroid中使用 fs_use_task 规则声明新的与文件有关的客体继承创建它们的进程的安全上下文。
使用基于任务的标记的文件系统不支持程序请求的标记，这种类型的标记行为多用于对于不真实存储用户数据但支持某种类型的内核资源的伪文件系统上。
在SEAndroid中sockfs，pipefs都是基于这一方式进行安全上下文的标记，具体被标记的安全上下文内容都在ocontexts文件中有详细声明。

基于转换的文件系统标记（fs_use_trans） 基于转换的文件系统标记与基于任务的文件系统标记非常类似，都使用的是伪文件系统，
不同的是基于转换的安全上下文标记是基于类型转换规则（type_transition）实现的。在这样的文件系统上创建的文件都需要有一套相关的type_transition规则来完成。
如果没有找到相应的type_transition规则，文件就会使用文件系统的初始安全上下文，文件系统的初始安全上下文被定义在了ocontexts文件中，
在SEAndroid中有devpfs、tmpfs、devtmpfs、shm、mqueue这些伪文件系统使用这一机制进行安全上下文标记。

一般方式标记安全上下文（genfscon）

genfscon语句用于运行时标记伪文件系统和不支持扩展属性的传统文件系统。在SEAndroid中文件系统rootfs、proc、selinuxfs、cgroup、sysfs、inotifyfs、vfat、debugfs、fuse，
都是采用这一方式进行安全上下文的标记，在ocontexts文件中定义了这些文件系统相应的安全上下文内容。

TE(Type Enforcement)

TE强制访问方式是SEAndroid中的最主要的安全手段，所有关于TE的强制访问规则都被定义在了后缀为te的文件中，在te文件中基本能总结为完成如下操作：
对type类型的定义和将type归到相应的attribute中
SEAndroid在te文件中定义了安全策略中最基本的参量type，同时将具有共性的type归在一起构成一个称为attribute的集合，policy的规则执行也能以attribute作为执行对象。

SEAndroid为所有type共定义了17个attribute：

domain: 这一attribute包含了如下所列的所有关于进程的type，通常策略中的访问主体也就是进程所在的domain都包含在了这一attribute中。

adbd
trusted_app
browser_app
untrusted_app
bluetoothd
gpsd
init
shell
su
system_app
system
zygote
…

dev_type:这一attribute包含了所有关于设备的type。

file_type: 这一attribute包含了所有存在于非伪文件系统的相关文件的type，

fs_type: 这一attribute包含了所有与文件系统相关的type。如下所列，大多是虚拟文件系统。

device
sockfs
rootfs
proc
selinuxfs
cgroup
sysfs
devpts
tmpfs
sdcard
debugfs
…

exec_type: 这一attribute包含了所有关于domian接入点的type，多被用在domain transition中，如下所列。

bluetoothd_exec
dbusd_exec
debuggerd_exec
drmserver_exec
gpsd_exec
installd_exec
keystore_exec
…..

data_file_type: 这一attribute包含了所有在/data目录下的文件type，如下所列。

system_data_file
anr_data_file
apk_data_file
dalvikcache_data_file
shell_data_file
gps_data_file
bluetoothd_data_file
bluetooth_data_file
wifi_data_file
radio_data_file
nfc_data_file
app_data_file
…

sysfs_type:这一attribute包含了在sysfs文件系统下的所有文件的type，在SEAndroid中只有sysfs_writable包含在这个attribute中。

node_type:这一attribute包含了所有与nodes/hosts有关的type，在SEAndroid中只有node包含在这个attribute中。

netif_type:这一attribute包含了所有与网络接口相关的type，在SEAndroid中只有netif包含在这个attribute中。

port_type:这一attribute包含了所有与网络端口相关的type，在SEAndroid中只有port包含在这个attribute中。

mlstrustedsubject:这一attribute包含了所有能越过MLS检查的主体domain。

mlstrustedobject:这一attribute包含了所有能越过MLS检查的客体type。

unconfineddomain:这一attribute包含了所有拥有无限权限的type。

appdomain:这一attribute包含了所有与app相关的type，

trusted_app

browser_app
untrusted_app
nfc
radio
shell
system_app

netdomain: 这一attribute包含了所有与需要访问网络的app相关的type，如下所列。
trusted_app
browser_app
gpsd
mediaserver
radio
rild
system

bluetoothdomain: 这一attribute包含了所有与需要访问bluetooth的app相关的type，如下所列。
trusted_app
radio
system

binderservicedomain:这一attribute包含了所有与binder服务相关的type，如下所列。
mediaserver
surfaceflinger
system

通过type_transition语句制定tpye类型转换规则

通过dontaudit语句声明对一些被安全策略拒绝的访问不再进行审核。

SEAndroid为系统定义了33个te策略文件，这33个策略文件是：

adbd.te、file.te、su.te、app.te、gpsd.te、netd.te、system.te、bluetoothd.te、init.te、net.te、ueventd.te、bluetooth.te、installd.te、nfc.te、unconfined.te、
cts.te、kernel.te、qemud.te、vold.te、dbusd.te、keystore.te、radio.te、wpa_supplicant.te、debuggerd.te、mediaserver.te、rild.te、zygote.te、device.te、servicemanager.te、
domain.te、shell.te、drmserver.te、surfaceflinger.te。

app.te

在这一文件里将安装在系统上的第三方app分类为受信任的app和不受信任的app，分别用不同的type表示，
再分别为这两种app在访问网络，bluetooth，sdcard，数据，缓存，binder等等名感位置时设置相应权限。

system.te
这一文件主要针对的是系统app和system server进程。对系统app访问binder、system data files、dalvikcatch、keystone等进行权限控制，
对system server访问网络、bluetooth、netlink、app、binder、device、data files、socket、cache files等进行权限控制。

init.te
在这一文件中声明了init拥有无限权限。

nfc.te
在这一文件中制定了nfc domain对nfc设备和相关数据文件的访问权限。

kernel.te
在这一文件中声明了kernel拥有无限权限。

radio.te
在这一文件中制定了radio domain对init、rild和相关数据文件的访问权限。

device.te
在这一文件中定义了所有跟设备相关的type，并将这些type都归到了dev_type属性中。

转换(transition)
domain transition

某个程序被执行时，其相应的进程会处在相应的domain中，但当程序根据需要又执行了另一个程序时，进程就需要根据type transition规则进行domain transition以获得必要的权限从而使新进程能顺利访问到相关文件。
另一个transition的原因是原有的domain权限过大，为了不让新启动的进程也继承过大的权限，因此需要domain transition。 在SEAndroid中几乎全部daemon进程都需要从init进程中启动，这就需要从init domian转换到daemon domain这一操作。
需要从init domain转换到daemon domain的进程有bluetoothd、dbusd、debuggerd、drmserver、gpsd、installd、keystore、mediaserver、netd、qemud、rild、servicemanager、surfaceflinger、vold、wpa_supplicant、zygote。
除了从init domain转换到其他daemon domain外，还有从adbd domain转换到shell domain，从shell domain转换到su domain，以及从zygote domain转换到system和appdomain，这主要是因为Android中的大部分进程都是由zygote创建。

type transition

type_transition 规则被用在Domain Transition中 或者确定新创建对象的标签，以重载其默认的、从父目录(containing directory)所继承的标签。通常情况下新创建文件的标签和其父目录的标签一致,但是可以使用type_transition规则为其指定特定的标签。
例如在SEAndroid中gpsd domain在以gps_data_file为type的目录下创建socket文件时，这些文件的type将会依照在策略中设定的type_transition规则而转换为gps_sokcket。
system domain在以wifi_data_file为type的目录下创建socket文件时，文件的type将会依照type_transition规则转变为system_wpa_socket。

文件和目录

在许多主体访问客体的情况中都需要对相关文件进行操作，SEAndroid对于牵涉到blk_file,chr_file,fd,fifo_file,lnk_file,sock_file和一般的file都进行了相关的策略制定。
还制定了一些domain指定type的目录、一般文件和链接文件只有读的权限的策略，例如dbusd domain对system type和bluetoothd type的目录和文件只有读的权限,domain attribute对proc、sysfs、inotify、cgroup这些虚拟文件系统中的文件和目录也只有读的权限，另外还有mediaserver domain对sdcard type的目录和文件只有读的权限，shell domain对apk_data_file的目录和文件只有读的权限、system domain对mediaserver和appdomain的目录和文件只有读的权限。
也制定了主体domain对不同文件系统的相关操作权限，以及当某个domain需要创建tmpfs、shmem、ashmem文件时，根据主体domain定义一个独特的type并对新创建的文件进行标记的策略。在SEAndroid里这条策略被用在了init、system、ueventd中。
无限权限[edit]

在SEAndroid中共定义了三个拥有巨大权限的attribute分别是mlstrustedsubject、mlstrustedobject、unconfineddomain，被分类到mlstrustedsubject的type在充当主体domain是可以越过MLS检查，被分类到mlstrustedobject的type在充当客体时可以越过MLS检查，被分到unconfineddomain的type则拥有所有权限可对客体进行任意操作。
在SEAndroid中被分在mlstrustedsubject attribute中的type有adbd、debuggerd、drmserver、init、installd、kernel、mediaserver、netd、surfaceflinger、su、system、vold、zygote。
被分在mlstrustedobject attribute中的type有alarm_device、ashmem_device、binder_device、log_device、mtp_device、nv_device、powervr_device、ptmx_device、null_device、cgroup、sysfs、sysfs_writable、sysfs_writable、sysfs_writable、debugfs、apk_data_file、cache_file、dnsproxyd_socket。
被分在unconfineddomain的type有init、kernel、su。

设备 关于设备这里重点提一下bluetooth，在SEAndroid中只对三个type提供bluetooth访问权限分别是trusted_app、radio、system。

App 在SEAndroid中指定了trusted_app、browser_app、untrusted_app、nfc、radio、shell、system_app这些type对系统中的所有app拥有适当的访问权限，并能对ashmem objects使用独特的type进行标记。

网络

SEAndroid对trusted_app、browser_app、gpsd、mediaserver、mediaserver、rild、system这些type授予了访问网络的权限。

在SEAndroid中系统对各类socket都制定了相应的策略，这些socket包括appletalk_socket(转为apple公司产品通信而设)、

dccp_socket、netlink_audit_socket、netlink_dnrt_socket、netlink_firewall_socket、netlink_ip6fw_socket、netlink_kobject_uevent_socket、netlink_nflog_socket、、
etlink_route_socket、netlink_selinux_socket、netlink_socket、netlink_tcpdiag_socket、netlink_xfrm_socket、packet_socket、rawip_socket、
tcp_socket、tun_socket、udp_socket、unix_dgram_socket、unix_stream_socket。

SEAndroid还指定了如下策略允许一个本地socket从指定的客户端domain通过指定的socket连接到指定的服务端domain，第一列是客户端domain，第二列是指定的socket，第三列是服务端domain。
SEAndroid只允许system和wpa这两个domain可以让一个本地socket以system和wpa任何一方为客户端另一方为服务端并通过某个socket进行数据包的发送。 运行一个本地socket从客户端domain通过发送数据包到服务端domain。

adbd, vold, vold
adbd, property, init
untrusted_app, dnsproxyd, netd
bluetoothd, dbus, dbusd
netdomain, dnsproxyd, netd
radio, property, init
radio, rild, rild
rild, property, init
rild, qemud, qemud
surfaceflinger, property, init
system_app, keystore, keystore
system, property, init
system, qemud, qemud
system, installd, installd
system, netd, netd
system, vold, vold
system, zygote, zygote
system, keystore, keystore
system, dbus, dbusd
system, gps, gpsd
system, bluetooth, bluetoothd
vold, property, init

IPC
SEAndroid只允许adbd、appdomain、drmserver、mediaserver、surfaceflinger、system这些type或attribute通过servicemanager使用binder IPC。
SEAndroid只允许指定的客户端domain对指定的服务端domain使用binder IPC，如以下所列，第一列是指定的客户端domain，第二列是指定的服务端domain。
adbd, surfaceflinger
trusted_app, appdomain
appdomain, binderservicedomain
appdomain, trusted_app
drmserver, system
mediaserver, binderservicedomain
mediaserver, appdomain
surfaceflinger, system
system_app, appdomain
system, binderservicedomain
system, appdomain

SEAndroid只允许指定的客户端domain传送由服务端创建的binder references，如以下所列，第一列是指定的客户端domain，第二列是指定的服务端domain。
trusted_app, appdomain
appdomain, binderservicedomain
appdomain, trusted_app
system_app, appdomain
system, binderservicedomain
system, appdomain

security level之间的三种运算关系：
dom

需要主体sensitiviety大于客体，同时客体的category是主体的一个子集。
domby

与dom完全相反eq
主体客体的sensitivity和category分别相同。

1.高的security level对低的security level拥有dom，
2.低的security level对高的security level关系为domby（与dom相反），
3.同级的security关系是eq，这三种关系运算符是SEAndroid中特有的。

MLS对进程的约束[edit]
限制进程的domain转换

对于从一个domain转换到另一个domain的操作要求两个domain的高级别security level和低级别security level同时相等才能许可转换，除非是待转换的domain属于对mls无限权限的type。
限制进程读操作

只有当主体domain的低级别security level对客体domain的低级别security level具有dom关系时，或者主体domian是属于对mls无限权限的type，主体才能对客体具有读操作的许可。

这一读操作具体是指：
能获取进程优先权
能获取另一进程的session id
能获取到进程的group id
能获取到系统的capabilities
能获取文件的属性信息
能追踪父程序或子程序的执行
允许通过clone或fork进程实现状态信息共享

总结一下就是MLS限制了低级别进程向高级别进程进行读的操作，即不能上读。
限制进程写操作

只有当主体domain的低级别security level对客体domain的低级别security level具有domby关系时，或者主体domain是属于对mls无限权限的type，主体才能对客体具有写操作的许可。

写操作具体是指：
能发送SIGKILL信号
能发送SIGSTOP信号
能发送一个非SIGKILL、SIGSTOP、SIGCHLD的信号
能设置进程优先级
能设置进程group id
能设置系统的capabilities
能改变进程hard limits
能追踪父程序或子程序的执行
允许通过clone或fork进程实现状态信息共享

总结一下就是MLS限制了高级别进程对低级别进程写的操作，即不能下写。

MLS对socket的约束[edit]
进程对local socket的访问限制

只有当主体进程的domain的高级别security level和低级别security level分别与客体local socket的type的security level相同时即满足eq关系时，或者主体客体任何一个具有对mls无限权限的type时，主体进程才对local socket拥有了某些访问权限。

这些访问权限是指：
读操作
写操作
新建操作
能获取对象属性信息
能设置对象的属性信息
能对对象重新标记安全上下文
能进行bind操作
能发起一个连接请求
能监听连接事件
能接受一个连接请求
能获取到socket options
能关闭socket连接
对socket的datagram发送的限制

只有当发送方的低级别security level与接受方的低级别security level满足domby关系时，或者主体客体任何一个具有对mls无限权限的type时，发送方才对接受方拥有了发送权限。
对客户端socket和服务端socket建立连接的限制

只有当客户端的低级别security level与服务端的低级别security level满足eq关系时，或者主体客体任何一个具有对mls无限权限的type时，客户端就能获得连接服务端的权限。
MLS对文件和目录的约束[edit]
对文件的创建和重新标记的限制

对文件操作时，要求客体的文件安全上下文只有一个security level即没有低级别和高级别security level或者说是这两个级别相同。 当主体domain的低级别security level对客体文件的低级别security level相同时，或者主体具有对mls有无限权限的type时，主体对客体文件拥有创建、和重新标记安全上下文的权限。
对目录的读操作的限制

只有当主体的低级别security level对客体目录的低级别security level满足dom关系时，或者主体客体任何一个具有对mls无限权限的type时，主体能对目录拥有如下权限：
能读目录
能获得目录的属性信息
能获得某个正在被访问文件的所有上层目录访问权（search权限）

总结一下就是对目录的访问不能上读。
对文件的读操作的限制

只有当主体的低级别security level对客体文件的低级别security level满足dom关系时，或者主体客体任何一个具有对mls无限权限的type时，主体能对文件拥有如下权限：
能读文件
能获得文件的属性信息
能执行该文件

总结一下就是对文件的访问不能上读。