android 8.1 安全机制 — SEAndroid & SELinux

1. SELinux 背景知识

1.1 DAC 与 MAC

在 SELinux 出现之前，Linux 上的安全模型叫 DAC，全称是 discretionary Access Control，翻译为自主访问控制。

DAC 的核心思想很简单，就是：进程理论上所拥有的权限与执行它的用户的权限相同。比如，以 root 用户启动 browser，那么 browser 就有 root 用户的权限，在 Linux 系统上能干任何事情。

显然，DAD 管理太过宽松，只要想办法在 Android 系统上获取到 root 权限就可以了。那么 SELinux 是怎么解决这个问题呢？在 DAC 之外，它设计了一种新的安全模型，叫 MAC（Mandatory Access Control），翻译为强制访问控制。

MAC 的理论也很简单，任何进程想在 SELinux 系统上干任何事情，都必须在《安全策略文件》中赋予权限，凡是没有出现在安全策略文件中的权限，就不行。

关于 DAC 和 MAC，可以总结几个知识点：

1. Linux 系统先做 DAC 检查。如果没有通过 DAC 权限检查，则操作直接失败。通过 DAC 检查之后，再做 MAC 权限检查
2. SELinux 有自己的一套规则来编写安全策略文件，这套规则被称之为 SELinux Policy 语言。

1.2 SEPolicy 语言

Linux中有两种东西，一种死的（Inactive），一种活的（Active）。死的东西就是文件（Linux哲学，万物皆文件。注意，万不可狭义解释为File），而活的东西就是进程。此处的 死 和 活 是一种比喻，映射到软件层面的意思是：进程能发起动作，例如它能打开文件并操作它。而文件只能被进程操作。

根据 SELinux 规范，完整的 Secure Context 字符串为：user:role:type[:range]

1.2.1 进程的 Secure Context

在 SELinux 中，每种东西都会被赋予一个安全属性，官方说法叫做 Security Context，Security Context 是一个字符串，主要由三个部分组成，例如 seandroid 中，进程的 Security Context 可通过 ps -Z 命令查看：

rk3288:/ $ ps -AZ
u:r:hal_wifi_supplicant_default:s0 wifi      1816     1   11388   6972 0                   0 S wpa_supplicant
u:r:platform_app:s0:c512,c768  u0_a14        1388   228 1612844  57396 0                   0 S android.ext.services
u:r:system_app:s0              system        1531   228 1669680 119364 0                   0 S com.android.gallery3d
u:r:kernel:s0                  root           582     2       0      0 0                   0 S [kworker/1:2]
u:r:radio:s0                   radio          594   228 1634876  89296 0                   0 S com.android.phone
u:r:system_app:s0              system         672   228 1686204 141716 0                   0 S com.android.settings
u:r:platform_app:s0:c512,c768  u0_a18         522   223 1721656 152116 0                   0 S com.android.systemUI

上面的最左边的一列就是进程的 Security Context，以第一个进程 wpa_supplicant 为例

u:r:hal_wifi_supplicant_default:s0

其中:

• u 为 user 的意思，seandroid 中定义了一个 SELinux 用户，值为 u
• r 为 role 的意思，role 是角色之意，它是 SELinux 中一个比较高层次，更方便的权限管理思路。简单点说，一个 u 可以属于多个 role，不同的 role 具有不同的权限。
• hal_wifi_supplicant_default 代表该进程所属的 Domain 为 hal_wifi_supplicant_default。MAC（Mandatory Access Control）强制访问控制 的基础管理思路其实是 Type Enforcement Access Control（简称TEAC，一般用TE表示），对进程来说，Type 就是 Domain，比如 hal_wifi_supplicant_default 需要什么权限，都需要通过 allow 语句在 te 文件中进行说明。
• s0 是 SELinux 为了满足军用和教育行业而设计的 Multi-Level Security（MLS）机制有关。简单点说，MLS 将系统的进程和文件进行了分级，不同级别的资源需要对应级别的进程才能访问

1.2.2 文件的 Secure Context

文件的 Secure Context 可以通过 ls -Z 来查看，如下

rk3288:/vendor/lib $ ls libOMX_Core.so -Z
u:object_r:vendor_file:s0 libOMX_Core.so

• u：同样是 user 之意，它代表创建这个文件的 SELinux user
• object_r：文件是死的东西，它没法扮演角色，所以在 SELinux 中，死的东西都用 object_r 来表示它的 role
• vendor_file：type，和进程的 Domain 是一个意思，它表示 libOMX_Core.so 文件所属的 Type 是 vendor_file
• s0：MLS 的等级

1.3 TE 介绍

MAC 基本管理单位是 TEAC（Type Enforcement Accesc Control），然后是高一级别的 Role Based Accesc Control。RBAC 是基于 TE 的，而 TE 也是 SELinux 中最主要的部分。上面说的 allow 语句就是 TE 的范畴。

根据 SELinux 规范，完整的 SELinux 策略规则语句格式为：

allow domains types:classes permissions;

- Domain - 一个进程或一组进程的标签。也称为域类型，因为它只是指进程的类型。
- Type - 一个对象（例如，文件、套接字）或一组对象的标签。
- Class - 要访问的对象（例如，文件、套接字）的类型。
- Permission - 要执行的操作（例如，读取、写入）。

= allow ： 允许主体对客体进行操作
= neverallow ：拒绝主体对客体进行操作
= dontaudit ： 表示不记录某条违反规则的决策信息
= auditallow ：记录某项决策信息，通常 SElinux 只记录失败的信息，应用这条规则后会记录成功的决策信息。

使用政策规则时将遵循的结构示例：

语句：
allow appdomain app_data_file:file rw_file_perms;

这表示所有应用域都可以读取和写入带有 app_data_file 标签的文件

—> 相关实例

1. seandroid 中的安全策略文件 policy.conf
# 允许 zygote 域中的进程向 init 域中的进程（Object Class 为 process）发送 sigchld 信号
allow zygote init:process sigchld;
2. # 允许 zygote 域中的进程 search 或 getattr 类型为 appdomain 的目录。
# 注意，多个 perm_set 可用 {} 括起来
allow zygote appdomain:dir { getattr search };

3. # perm_set 语法比较奇特，前面有一个 ~ 号。
   # 它表示除了{entrypoint relabelto}之外，{chr_file #file}这两个object_class所拥有的其他操作 
  allow unconfineddomain {fs_type dev_type file_type}:{ chr_file file }   \
  ~{entrypoint relabelto};

Android NDK-arm-linux-androideabi-g：找不到

我正在尝试在刚为此安装的新Ubuntu中为Android目标构建C POCO库.

我已经在/ home / user / dev / Android / android-ndk-r9-x86中安装了Android NDK,并使用以下命令在环境变量中添加了NDK的路径：

导出ANDROID_NDK_ROOT = / home / user / dev / Android / android-ndk-r9-x86

要构建库,我首先移至POCO库的根目录,并使用进行配置：

./configure --omit=NetSSL_OpenSSL,Crypto,Data/ODBC,Data/MysqL --static --config=Android

这样它可以编译静态.a库,不编译我不需要的模块,并为Android目标编译.

但是比调用make会导致以下错误：

user@user-VirtualBox:~/dev/Lib/POCO/poco-1.6.1$make
make -C /home/user/dev/Lib/POCO/poco-1.6.1/Foundation
make[1]: Entering directory `/home/user/dev/Lib/POCO/poco-1.6.1/Foundation'
** Compiling src/ArchiveStrategy.cpp (debug, static)
arm-linux-androideabi-g++  -Iinclude -I/home/user/dev/Lib/POCO/poco-1.6.1/CppUnit/include -I/home/user/dev/Lib/POCO/poco-1.6.1/CppUnit/WinTestRunner/include -I/home/user/dev/Lib/POCO/poco-1.6.1/Foundation/include -I/home/user/dev/Lib/POCO/poco-1.6.1/XML/include -I/home/user/dev/Lib/POCO/poco-1.6.1/JSON/include -I/home/user/dev/Lib/POCO/poco-1.6.1/Util/include -I/home/user/dev/Lib/POCO/poco-1.6.1/Net/include -mthumb -fpic -ffunction-sections -funwind-tables -fstack-protector -fno-strict-aliasing -finline-limit=64 -frtti -fexceptions -DPOCO_BUILD_HOST=user-VirtualBox  -DPOCO_ANDROID -DPOCO_NO_FPENVIRONMENT -DPOCO_NO_WSTRING -DPOCO_NO_SHAREDMEMORY  -g -D_DEBUG  -c src/ArchiveStrategy.cpp -o /home/user/dev/Lib/POCO/poco-1.6.1/Foundation/obj/Android/armeabi/debug_static/ArchiveStrategy.o
sh: 1: arm-linux-androideabi-g++: not found
make[1]: *** [/home/user/dev/Lib/POCO/poco-1.6.1/Foundation/obj/Android/armeabi/debug_static/ArchiveStrategy.o] Error 127
make[1]: Leaving directory `/home/user/dev/Lib/POCO/poco-1.6.1/Foundation'
make: *** [Foundation-libexec] Error 2

Make似乎找不到用于Android的编译器,我也不知道为什么？我想念什么？ “安装” NDK时我是否忘记了什么？

谢谢.

解决方法:

您遇到的错误是由于缺少工具链调用引起的-确切地说,找不到arm-linux-androideabi-g命令/可执行文件/二进制文件.

幸运的是,我们可以通过安装Standalone toolchain来解决该问题-实际上,它确实具有您所缺少的东西,这是一种通用的arm-linux-androideabi交叉编译器,而不是其他一些晦涩的,特定于供应商/平台的交叉编译器交叉编译器/工具链,例如marvell使用的armv7a-marvell-linux-android或CLang使用的arm-linux-android.有关CLang,look here的更多信息.我可能是错的,并且CLang实际上开箱即用生成了arm-linux-androideabi工具链,但我不确定.我知道您可以轻松使用它,只是不确定是否可以“直接使用”它,这正是您所要的. “剩下的工作”只是一些途径的输出,但仍然如此.我们的目标是在这里提供最懒惰的解决方案.

独立的工具链应足以完成您的任务,因此请尝试在其他任何交叉编译解决方案中尽可能多地使用它.

但是,如果您喜欢冒险-可以使用crosstool-ng工具随意创建自己的交叉编译器(或整个工具链！).但是,请尝试使用Linaro libc分支.亲身经历告诉我,某种方式效果最好,而造成的问题/时间浪费最少.

编辑：

另外,请确保为您的体系结构(架构)和操作系统下载正确的版本,这里也涉及32位和64位.经过长时间的讨论,我们意识到这是一个“ 32位与64位”的问题.
Here’s a link了解更多信息.

Android SELinux AVC约束违规

#!!!! This avc is a constraint violation.  You would need to modify the attributes of either the source or target types to allow this access.
#Constraint rule: 
#   mlsconstrain chr_file { write setattr append unlink link rename } ((t2 == app_data_file -Fail-)  or (l1 eq l2 -Fail-)  or (t1 == mlstrustedsubject -Fail-)  or (t2 == mlstrustedobject -Fail-) ); Constraint DENIED

#   Possible cause is the source level (s0:c79,c256,c512,c768) and target level (s0) are different.