1.前言
在Linux中NSN开发了SELinux，来保护linux系统的安全，因为Android有着独特的用户运行时空间，
所以SELinux并不完全适用Android，故而在SELinux的基础上有了SEAndroid，SEAndroid主要保护的
对象就是系统中的资源例如文件，属性等和系统中的进程,Socket,IPC等。
2.SELinux的整体结构
在SEAndroid的整体结构中，通过SELinux的文件系统，将其划分为了用户空间和内核空间。用户空间中包含了
Security Context,Security Server,selinux库libselinux。内核空间包含了LSM.
1.Security Context:描述了对象安全上下，安全策略就是由资源安全上下文决定的
2.Security Server:一方面到Security Context中去检索安全上下文，另一方面也到内核空间操作安全上下文
3.SEAndroid Policy:安全策略。在系统启动的时候，Security Server会将其加载到内核空间的LSM中。
4.libselinux:是SELinux库，可以用来读写SELinux文件系统，加载SEAndroid Policy,检索和操作安全上下文等都是由libselinux完成的
5.LSM:负责内核资源的访问控制
3.内核空间
LSM：LSM是内核MAC机制的一个通用的模块，而SEAndroid仅仅是LSM的一个实现。这体现了内核设计的一个思想。在LSM中包含了Access Vector Cache
和Security Server两个模块。当要访问一个资源的时候，首先会到Access Vector Cache检查是否允许访问，如果不允许访问，则到Security Server
中查询是否可以访问，如果可以访问在访问的同时，也会在Access Vector Cache中将结果进行保存。
SELinux LSM 和内核子系统的交互：当访问内核子系统中的资源的时候，LSM就会调用他的Hook代码，而Hook代码就会回调SELinux中的回调方法。
例如当调用系统的read函数的时候，进入到内核子系统中的文件系统。在文件子系统中负责读取文件的vfs_read函数，就会回调LSM加入的Hook代码，
Hook代码就会回调SELinux中的回调函数，以确保安全性的检查
安全访问资源的流程:
进行了三次错误性检查：
1. 检查对象是否存在，访问参数是否正确等
2. Linux UID/GID是否允许
3. 安全策略是否允许
4.用户空间
1.Security Context:对象安全上下文，用来定制安全策略。由用户，角色，类型和安全级别组成。在第一篇文章我们可知
查看上下文的方法。对象安全上下文又分为主体（指进程）和客体（指资源如文件等）。
其实用户和角色并不重要，重要的是类型。下面分别来对其进行介绍。
用户和角色只是用来限制进程可以标注的类型，而对文件来说是可以完成不记的。对所有主体和客体来说，只有一个SELinux用户，那就是
u(系统中只定义了这一个SELinux用户)，对客体来说通常将它的角色定为object_r。而对所有的主体来说，只定义了一个角色那就是r。
在src/system/sepolicy/private/users中可以看到系统定义的SELinux用户
user u roles { r } level s0 range s0 - mls_systemhigh;
表明了一个SELinux的用户u,他可用的角色为r,安全级别默认为s0，而安全级别的范围为s0-mls_systemhigh
在src/system/sepolicy/private/roles_decl中可以看到角色的定义
role r;
在src/system/sepolicy/public/roles中可以看到角色可以关联的类型:
role r types domain;
表明角色r可以关联的类型为domain
可以看到u和r关联，而r又和类型domain关联。换句话说如果没有定义其他的用户，角色和类型，那么只有u,r和domain的组合才是正确的。
可是我们又会看到
$ ps -Z
LABEL USER PID PPID NAME
u:r:init:s0 root 1 0 /init
难道u:r:init:s0的组合是错误的吗？当然不是了。在src/system/sepolicy/public/init.te中
type init, domain, mlstrustedsubject;表明了将domain定义为init的属性，那么能用domain的地方就能用init.所以上面的说法也是正确的。
安全级别：在SELinux中安全级别是由敏感性(sensitivity)和类别(category)两部分组成的.但是类别这部分是可以省略的。一般的形式为sensitivity[:category]
如由敏感性s0和策略c0,c1组成的安全级别就为s0[:c0,c1]. 在SEAndroid中，低安全级别可以向高安全级别的写入数据，但是不能读。高安全级别的可以读取低安全
级别的数据，但是不能写入。如果两个安全级别是相同的，那么既可以读又可以写。
类型：类型是SEAndroid中最为重要的。在src/system/sepolicy/public/roles中我们可以看到
role r types domain
domain表示的是进程的类型。每一个进程的类型都会将domain作为属性，每一个文件的类型都会将file_context作为属性。
那么安全策略又是如何定义的呢？
主要分析四种安全策略的定义,app进程，app数据文件，系统文件已经系统属性。与其相关的文件有
src/system/sepolicy/private/mac_permissions.xml,src/system/sepolicy/private/seapp_contexts,src/system/sepolicy/private/file_contexts,
property_contexts.
安全策略的确定首先要确定安全上下文，其实也就是确定最为重要的类型。
看mac_permissions.xml
<?xml version="1.0" encoding="utf-8"?> <policy> <!-- * A signature is a hex encoded X.509 certificate or a tag defined in keys.conf and is required for each signer tag. The signature can either appear as a set of attached cert child tags or as an attribute. * A signer tag must contain a seinfo tag XOR multiple package stanzas. * Each signer/package tag is allowed to contain one seinfo tag. This tag represents additional info that each app can use in setting a SELinux security context on the eventual process as well as the apps data directory. * seinfo assignments are made according to the following rules: - Stanzas with package name refinements will be checked first. - Stanzas w/o package name refinements will be checked second. - The "default" seinfo label is automatically applied. * valid stanzas can take one of the following forms: --> <!-- Platform dev key in AOSP --> <signer signature="@PLATFORM" > <seinfo value="platform" /> </signer> <!-- Media key in AOSP --> <signer signature="@MEDIA" > <seinfo value="media" /> </signer> </policy>
如果我们的app使用的是系统的签名，那么从该文件中得知，对应的seinfo为platform.从当前代码中我们可以看到系统只提供了两个签名（nexus8.1的代码）,如果
还有其他的签名的app怎么办？从注释中我们可以看到，它将会用seinfo为"default"。seinfo并不是app进程的类型，接下来再看seapp_contexts文件
# Input selectors:
# isSystemServer (boolean)
# isEphemeralApp (boolean)
# isV2App (boolean)
# isOwner (boolean)
# user (string)
# seinfo (string)
# name (string)
# path (string)
# isPrivApp (boolean)
# minTargetSdkVersion (unsigned integer)
# isSystemServer=true can only be used once.
# An unspecified isSystemServer defaults to false.
# isEphemeralApp=true will match apps marked by PackageManager as Ephemeral
# isV2App=true will match apps in the v2 app sandbox.
# isOwner=true will only match for the owner/primary user.
# isOwner=false will only match for secondary users.
# If unspecified, the entry can match either case.
# An unspecified string selector will match any value.
# A user string selector that ends in * will perform a prefix match.
# user=_app will match any regular app UID.
# user=_isolated will match any isolated service UID.
# isPrivApp=true will only match for applications preinstalled in
# /system/priv-app.
# minTargetSdkVersion will match applications with a targetSdkVersion
# greater than or equal to the specified value. If unspecified,
# it has a default value of 0.
# All specified input selectors in an entry must match (i.e. logical AND).
# Matching is case-insensitive.
......
#
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
user=radio seinfo=platform domain=radio type=radio_data_file
user=shared_relro domain=shared_relro
user=shell seinfo=platform domain=shell type=shell_data_file
user=_isolated domain=isolated_app levelFrom=user
user=_app seinfo=media domain=mediaprovider name=android.process.media type=app_data_file levelFrom=user
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user
user=_app isV2App=true isEphemeralApp=true domain=ephemeral_app type=app_data_file levelFrom=user
user=_app isPrivApp=true domain=priv_app type=app_data_file levelFrom=user
user=_app minTargetSdkVersion=26 domain=untrusted_app type=app_data_file levelFrom=user
user=_app domain=untrusted_app_25 type=app_data_file levelFrom=user
当在mac_permissions.xml中查询到seinfo信息后，就会到该文件查询对应类型。如platform对应的app的进程的类型就为platform_app,而由该app创建的文件的类型
就为app_data_file。而对于seinfo为default的app进程的类型为untrusted_app_25,由该app进程所创建的文件的类型为app_data_file.知道了安全上下文是如何定义的
之后就可以看看安全策略是如何定义的了。
继续看init.te文件
ypeattribute init coredomain; tmpfs_domain(init) # Transitions to seclabel processes in init.rc domain_trans(init, rootfs, charger) domain_trans(init, rootfs, healthd) domain_trans(init, rootfs, slideshow) domain_auto_trans(init, e2fs_exec, e2fs) recovery_only(` domain_trans(init, rootfs, adbd) domain_trans(init, rootfs, recovery) ') domain_trans(init, shell_exec, shell) domain_trans(init, init_exec, ueventd) domain_trans(init, init_exec, watchdogd) domain_trans(init, { rootfs toolbox_exec }, modprobe) # case where logpersistd is actually logcat -f in logd context (nee: logcatd) userdebug_or_eng(` domain_auto_trans(init, logcat_exec, logpersist) ')
可以看到类似于tmpfs_domain(init)的调用，这是所定义的宏，为init类型添加一些权限
再看文件src/system/sepolicy/te_macros
......
define(`tmpfs_domain', `
type $1_tmpfs, file_type;
type_transition $1 tmpfs:file $1_tmpfs;
allow $1 $1_tmpfs:file { read write getattr };
allow $1 tmpfs:dir { getattr search };
')
......
可以看到tmpfs_domain为将file_type设置为init_tmpfs的属性，那么init_tmpfs将也是描述文件的类型，之后还通过allow语句为init设置了其他权限。
系统文件的权限设置。file_contexts文件中的内容如下
......
/system(/.*)? u:object_r:system_file:s0
/system/bin/atrace u:object_r:atrace_exec:s0
/system/bin/e2fsdroid u:object_r:e2fs_exec:s0
/system/bin/mke2fs u:object_r:e2fs_exec:s0
/system/bin/e2fsck -- u:object_r:fsck_exec:s0
/system/bin/fsck\.f2fs -- u:object_r:fsck_exec:s0
/system/bin/make_f2fs -- u:object_r:fsck_exec:s0
/system/bin/fsck_msdos -- u:object_r:fsck_exec:s0
/system/bin/tune2fs -- u:object_r:fsck_exec:s0
/system/bin/toolbox -- u:object_r:toolbox_exec:s0
/system/bin/toybox -- u:object_r:toolbox_exec:s0
/system/bin/logcat -- u:object_r:logcat_exec:s0
/system/bin/logcatd -- u:object_r:logcat_exec:s0
/system/bin/sh -- u:object_r:shell_exec:s0
/system/bin/run-as -- u:object_r:runas_exec:s0
/system/bin/bootanimation u:object_r:bootanim_exec:s0
/system/bin/bootstat u:object_r:bootstat_exec:s0
/system/bin/app_process32 u:object_r:zygote_exec:s0
/system/bin/app_process64 u:object_r:zygote_exec:s0
/system/bin/servicemanager u:object_r:servicemanager_exec:s0
/system/bin/hwservicemanager u:object_r:hwservicemanager_exec:s0
/system/bin/surfaceflinger u:object_r:surfaceflinger_exec:s0
/system/bin/bufferhubd u:object_r:bufferhubd_exec:s0
/system/bin/performanced u:object_r:performanced_exec:s0
/system/bin/drmserver u:object_r:drmserver_exec:s0
/system/bin/dumpstate u:object_r:dumpstate_exec:s0
/system/bin/incident u:object_r:incident_exec:s0
/system/bin/incidentd u:object_r:incidentd_exec:s0
/system/bin/netutils-wrapper-1\.0 u:object_r:netutils_wrapper_exec:s0
/system/bin/vold u:object_r:vold_exec:s0
/system/bin/netd u:object_r:netd_exec:s0
/system/bin/wificond u:object_r:wificond_exec:s0
/system/bin/audioserver u:object_r:audioserver_exec:s0
/system/bin/mediadrmserver u:object_r:mediadrmserver_exec:s0
/system/bin/mediaserver u:object_r:mediaserver_exec:s0
/system/bin/mediametrics u:object_r:mediametrics_exec:s0
/system/bin/cameraserver u:object_r:cameraserver_exec:s0
/system/bin/mediaextractor u:object_r:mediaextractor_exec:s0
/system/bin/mdnsd u:object_r:mdnsd_exec:s0
/system/bin/installd u:object_r:installd_exec:s0
/system/bin/otapreopt_chroot u:object_r:otapreopt_chroot_exec:s0
/system/bin/otapreopt_slot u:object_r:otapreopt_slot_exec:s0
/system/bin/keystore u:object_r:keystore_exec:s0
/system/bin/fingerprintd u:object_r:fingerprintd_exec:s0
/system/bin/gatekeeperd u:object_r:gatekeeperd_exec:s0
/system/bin/crash_dump32 u:object_r:crash_dump_exec:s0
......
/system(/.*)? u:object_r:system_file:s0 表明了在system目录中的文件的安全上下文都是u:object_r:system_file:s0.
但是在之后，发现对system中的一些文件进行了详细的安全上下文的定义。所以这些文件的安全上下文，由最后以单独定义的安全上下文为主。
再看属性上下文的定义，文件property_contexts的内容如下：
......
net.rmnet u:object_r:net_radio_prop:s0
net.gprs u:object_r:net_radio_prop:s0
net.ppp u:object_r:net_radio_prop:s0
net.qmi u:object_r:net_radio_prop:s0
net.lte u:object_r:net_radio_prop:s0
net.cdma u:object_r:net_radio_prop:s0
net.dns u:object_r:net_dns_prop:s0
sys.usb.config u:object_r:system_radio_prop:s0
ril. u:object_r:radio_prop:s0
ro.ril. u:object_r:radio_prop:s0
gsm. u:object_r:radio_prop:s0
persist.radio u:object_r:radio_prop:s0
......
由net.rmnet可以指定，只有能够访问类型为net_radio_prop的进程才能访问这个属性。
当在用户空间完成策略的定义之后，还需要在系统开机的时候把它加载到内核的LMS模块中，这主要是借助了libselinux来实现。
在src/system/core/init/init.cpp中可以看到
int main(int argc, char** argv) { ......
if (is_fist_stage){
mount("selinuxfs", "/sys/fs/selinux", "selinuxfs", 0, NULL);// Set up SELinux, loading the SELinux policy. selinux_initialize(true);
...... }
return 0; }
在init的初始化的第一阶段会做如下几件事：
1.将selinux系统挂载在/sys/fs/selinux
2.调用selinux_initialize(true)对selinux策略进行初始化
selinux_initialize函数也是在init.cpp中定义，内容如下：
static void selinux_initialize(bool in_kernel_domain) { Timer t; selinux_callback cb; cb.func_log = selinux_klog_callback; selinux_set_callback(SELINUX_CB_LOG, cb); cb.func_audit = audit_callback; selinux_set_callback(SELINUX_CB_AUDIT, cb); if (in_kernel_domain) { LOG(INFO) << "Loading SELinux policy"; if (!selinux_load_policy()) { panic(); } bool kernel_enforcing = (security_getenforce() == 1); bool is_enforcing = selinux_is_enforcing(); if (kernel_enforcing != is_enforcing) { if (security_setenforce(is_enforcing)) { PLOG(ERROR) << "security_setenforce(%s) failed" << (is_enforcing ? "true" : "false"); security_failure(); } } std::string err; if (!WriteFile("/sys/fs/selinux/checkreqprot", "0", &err)) { LOG(ERROR) << err; security_failure(); } // init's first stage can't set properties, so pass the time to the second stage. setenv("INIT_SELINUX_TOOK", std::to_string(t.duration().count()).c_str(), 1); } else { selinux_init_all_handles(); } }
1.首先是设置selinux回调
2.调用selinux_load_policy加载SELinux policy
3.设置selinux的模式。在开启了selinux的系统中，通过getenforce可以看到系统中selinux的模式。有Enforcing和Permissive。Enforcing即为生效。
permissive为即使违反了SELinux policy，只做提示但不拒绝。
selinux_load_policy函数同样是在init.cpp中
static bool selinux_load_policy() { return selinux_is_split_policy_device() ? selinux_load_split_policy() : selinux_load_monolithic_policy(); }
selinux_is_split_policy_device()同样是在init.cpp中，这个函数主要是判断"/system/etc/selinux/plat_sepolicy.cil"这个文件是否是可用的
可用时就会调用selinux_load_split_policy()否则调用selinux_load_monolithic_policy()。
先看selinux_load_split_policy()
static bool selinux_load_split_policy() { // IMPLEMENTATION NOTE: Split policy consists of three CIL files: // * platform -- policy needed due to logic contained in the system image, // * non-platform -- policy needed due to logic contained in the vendor image, // * mapping -- mapping policy which helps preserve forward-compatibility of non-platform policy // with newer versions of platform policy. // // secilc is invoked to compile the above three policy files into a single monolithic policy // file. This file is then loaded into the kernel. // Load precompiled policy from vendor image, if a matching policy is found there. The policy // must match the platform policy on the system image. std::string precompiled_sepolicy_file; if (selinux_find_precompiled_split_policy(&precompiled_sepolicy_file)) { android::base::unique_fd fd( open(precompiled_sepolicy_file.c_str(), O_RDONLY | O_CLOEXEC | O_BINARY)); if (fd != -1) { if (selinux_android_load_policy_from_fd(fd, precompiled_sepolicy_file.c_str()) < 0) { LOG(ERROR) << "Failed to load SELinux policy from " << precompiled_sepolicy_file; return false; } return true; } } // No suitable precompiled policy could be loaded LOG(INFO) << "Compiling SELinux policy"; // Determine the highest policy language version supported by the kernel set_selinuxmnt("/sys/fs/selinux"); int max_policy_version = security_policyvers(); if (max_policy_version == -1) { PLOG(ERROR) << "Failed to determine highest policy version supported by kernel"; return false; } // We store the output of the compilation on /dev because this is the most convenient tmpfs // storage mount available this early in the boot sequence. char compiled_sepolicy[] = "/dev/sepolicy.XXXXXX"; android::base::unique_fd compiled_sepolicy_fd(mkostemp(compiled_sepolicy, O_CLOEXEC)); if (compiled_sepolicy_fd < 0) { PLOG(ERROR) << "Failed to create temporary file " << compiled_sepolicy; return false; } // Determine which mapping file to include std::string vend_plat_vers; if (!selinux_get_vendor_mapping_version(&vend_plat_vers)) { return false; } std::string mapping_file("/system/etc/selinux/mapping/" + vend_plat_vers + ".cil"); const std::string version_as_string = std::to_string(max_policy_version); // clang-format off const char* compile_args[] = { "/system/bin/secilc", plat_policy_cil_file, "-M", "true", "-G", "-N", // Target the highest policy language version supported by the kernel "-c", version_as_string.c_str(), mapping_file.c_str(), "/vendor/etc/selinux/nonplat_sepolicy.cil", "-o", compiled_sepolicy, // We don't care about file_contexts output by the compiler "-f", "/sys/fs/selinux/null", // /dev/null is not yet available nullptr}; // clang-format on if (!fork_execve_and_wait_for_completion(compile_args[0], (char**)compile_args, (char**)ENV)) { unlink(compiled_sepolicy); return false; } unlink(compiled_sepolicy); LOG(INFO) << "Loading compiled SELinux policy"; if (selinux_android_load_policy_from_fd(compiled_sepolicy_fd, compiled_sepolicy) < 0) { LOG(ERROR) << "Failed to load SELinux policy from " << compiled_sepolicy; return false; } return true; }
这个函数主要做三件事：
1.通过selinux_find_precompiled_split_policy函数检查系统中是否存在预编译的CIL格式的策略文件。CIL格式的策略文件存在三种类型系统所要用的，
厂商要使用的和帮助厂商实现向前兼容。
2.如果已经存在预编译好的策略文件就直接进行加载，如果不存在则调用secilc，对策略文件进行编译。
3.获取到策略文件后调用selinux_android_load_policy_from_fd函数将策略文件添加到内核的LSM中。这个函数是libselinux中的
在src/external/selinux/libselinux/src/android/android_platform.c中
int selinux_android_load_policy_from_fd(int fd, const char *description) { int rc; struct stat sb; void *map = NULL; static int load_successful = 0; /* * Since updating policy at runtime has been abolished * we just check whether a policy has been loaded before * and return if this is the case. * There is no point in reloading policy. */ if (load_successful){ selinux_log(SELINUX_WARNING, "SELinux: Attempted reload of SELinux policy!/n"); return 0; } set_selinuxmnt(SELINUXMNT); if (fstat(fd, &sb) < 0) { selinux_log(SELINUX_ERROR, "SELinux: Could not stat %s: %s\n", description, strerror(errno)); return -1; } map = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0); if (map == MAP_FAILED) { selinux_log(SELINUX_ERROR, "SELinux: Could not map %s: %s\n", description, strerror(errno)); return -1; } rc = security_load_policy(map, sb.st_size); if (rc < 0) { selinux_log(SELINUX_ERROR, "SELinux: Could not load policy: %s\n", strerror(errno)); munmap(map, sb.st_size); return -1; } munmap(map, sb.st_size); selinux_log(SELINUX_INFO, "SELinux: Loaded policy from %s\n", description); load_successful = 1; return 0; }
该函数会将SEAndroid的策略添加到LSM中。
1.判断之前是否加载过，如果加载过则不再加载
2.将策略文件添加到内存中
3.调用security_load_policy将安全策略添加到LSM中。security_load_policy在src/external/selinux/libselinux/src/load_policy.c
int security_load_policy(void *data, size_t len) { char path[PATH_MAX]; int fd, ret; if (!selinux_mnt) { errno = ENOENT; return -1; } snprintf(path, sizeof path, "%s/load", selinux_mnt); fd = open(path, O_RDWR | O_CLOEXEC); if (fd < 0) return -1; ret = write(fd, data, len); close(fd); if (ret < 0) return -1; return 0; }
selinux_mnt最终的值为/sys/fs/selinux或者为/selinux.
判断selinux_mnt是否存在，如果存在就打开该文件将安全策略写入到该文件中。其实将安全策略加载到LSM中就是将安全策略写入到该文件中，从此内核和selinux
的交互就是通过该文件。
再看selinux_load_monolithic_policy()
static bool selinux_load_monolithic_policy() { LOG(VERBOSE) << "Loading SELinux policy from monolithic file"; if (selinux_android_load_policy() < 0) { PLOG(ERROR) << "Failed to load monolithic SELinux policy"; return false; } return true; }
可以看到会调用selinux_android_load_policy(),该函数在src/external/selinux/libselinux/src/android/android_platform.c中
int selinux_android_load_policy() { int fd = -1; fd = open(sepolicy_file, O_RDONLY | O_NOFOLLOW | O_CLOEXEC); if (fd < 0) { selinux_log(SELINUX_ERROR, "SELinux: Could not open %s: %s\n", sepolicy_file, strerror(errno)); return -1; } int ret = selinux_android_load_policy_from_fd(fd, sepolicy_file); close(fd); return ret; }
sepolicy_file的值为/sepolicy，该函数主要就是打开该文件，之后调用selinux_android_load_policy_from_fd这个函数。
2.Security Server
Security Server是用来保护用户空间的资源和访问内核空间对象的安全上下文的。它由应用程序安装服务PackageManagerService,应用程序安装守护进程
Installd,创建应用程序进程Zygote,以及init进程。
PackageManagerService和Installd负责创建app的数据目录。在创建数据目录时，PackageManagerService会根据包名或者签名查询mac_permission.xml文件
找到与之对应的seinfo，之后将seinfo传递给Installd,Installd根据libselinux提供的selable_lookup查询seapp_contexts文件得到与之对应的类型，设置
该app数据目录的安全上下文。
当ActivityManagerService向Zygote发出创建app进程的请求的时候，ActivityManagerService会去PackageManagerService找到对应的seinfo，并且将其传递
给Zygote，Zygote根据libselinux提供的setlabel_lookup找到对应的类型，设置该app进程的安全上下文。
在系统启动的时候，init进程会维护一段内存空间存放系统属性，并且启动Property服务，Property提供Socket接口，供其他进程访问系统属性。当其他进程访
问系统属性的时候，Property会获取到该进程的安全上下文，之后会去property_contexts，查询该属性的安全上下文，以此来判断该进程是否可以访问该属性。
