Selinux&SeAndroid学习总结

一、Selinux相关概念

DAC 与 MAC—自助式访问控制 与 强制访问控制

Linux上传统的访问控制标准是自主访问控制Discretionary Access Control（DAC）。这种形式下一个软件或守护进程以User ID（UID）或Set owner User ID（SUID）的身份运行，并且拥有该用户的目标（文件、套接字、以及其它进程）权限。这使得恶意代码很容易运行在特定权限之下，从而取得访问关键的子系统的权限。
强制访问控制Mandatory Access Control（MAC）对系统中的资源分密级和类别进行管理，保证每个用户只能访问那些明确授权可以访问的资源，该限制单元独立于传统的Linux安全机制运作，并且没有超级用户的概念。
注意，当DAC和MAC并存，在一次访问过程中，系统先进行DAC检查，通过后再进行MAC检查。

传统自助访问控制DAC介绍—基于Linux GID/UID机制的

资源访问权限有访问主体（如进程）和客体（如文件）的属性决定，可以通过ls -al查看其属性（文件类型+属主权限+属组权限+其他用户权限）。运行期间资源的所有者（属主和同组成员）可以修改其权限用以被其他主体访问，如chmod 777 xxx.png;

ls -al
drwxr-xr-x 133 root root      12288 Aug 26 16:37 etc
drwxr-xr-x   4 root root       4096 Jun  6  2020 home
lrwxrwxrwx   1 root root         33 Jun  9  2020 initrd.img -> boot/initrd.img-4.4.0-148-generic
lrwxrwxrwx   1 root root         33 Jun  9  2020 initrd.img.old -> boot/initrd.img-4.4.0-142-generic

Selinux—一种基于域-类型模型的强制访问控制（MAC）安全系统

安全增强型 Linux（Security-Enhanced Linux）简称 SELinux，它是一个 Linux 内核模块，也是 Linux 的一个安全子系统。由美国国家安全局开发。2.6 及以上版本的 Linux 内核都已经集成了 SELinux 模块。将系统中的资源分密级和类别进行管理，保证每个用户只能访问那些明确授权可以访问的资源，制定访问者与被访问资源之间的访问规则。　SELinux 主要作用就是最大限度地减小系统中服务进程可访问的资源（最小权限原则）。

SeAndroid—Android推出一套以SELinux为核心的系统安全机制

从Android 4.3开始，Android 使用安全增强型 Linux (SELinux) 对所有进程强制执行强制访问控制，甚至包括以 Root/超级用户权限运行的进程。更好地保护和限制系统服务、控制对应用数据和系统日志的访问、降低恶意软件的影响。如果需要通过Android的CTS认证，必须要让Selinux使能并处于强制模式。 打开Selinux必然会对性能有一定影响。

二、Selinux规则详解

由于SeAndroid是基于Selinux的，后续内容描述没有他们割离开来将，涉及android部分即SeAndroid相关扩展；

2.1 Selinux编译配置—要使用要先编译进入内核

首先，Selinux是一个内核子模块，无论启动后需要将Selinux工作在任何模式，需要先在内核编译时带上他。
在内核中启用 SELinux：CONFIG_SECURITY_SELINUX=y
一般情况，启动时处于强制模式还是宽容模式，常用bootargs来进行配置传递给kernel进行默认初始值设置，有些linux版本通过配置文件/etc/selinux/config来记录启动默认值，看实际玩法。
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive

2.2 Selinux三种基本模式—disable/permissive/enforcing

当编译进入内核后，启动kernel之后，Selinux状态(模式)有如下三种：
1、disabled 关闭selinux，完全失效；
2、permissvie 宽容模式，发生违反权限事件，只记录日志，并不禁止操作；
3、enforcing 强制模式，发生违反权限事件，记录日志并禁止操作；
状态查看命令：getenforce；（会显示是：Disabled, permissvie, enforcing）
宽容与强制模式切换命令：setenforce 0/1；（0表示宽容模式，1表示强制模式，需要root权限）

2.3 Selinux安全策略Policy的制定

安全策略（规则）就是描述 ：允许 谁 能对 什么资源 做什么事情，或者 禁止 谁 对 什么资源 做什么事情。用于判定操作合法性。

安全上下文security context概念—描述访问主客体

安全上下文就是一个标签Label，用来标识对象的安全所属范围，即 描述在权限规则中 主体或客体 “谁” 这一个概念。
安全上下文的典型定义：usr:role:type:sensitivity;（其中usr在SeAndroid值固定u，role可以为r表示主体或者objpect_r表示客体，sensitivity为s0等级，type就是重点表诉 在安全规则中 是 谁 这一概念）
查看方法：
（1）进程类（服务、APK），ps带上-Z命令即显示安全上下文的标签：
第一列即是，注意app主要分三类：untrusted_app（第三方应用），platform_app（有平台签名应用），system_app（有平台签名，并且有system权限的应用）

HWRVL:/ $ ps -A -Z
LABEL                          USER           PID  PPID     VSZ    RSS WCHAN            ADDR S NAME
u:r:init:s0                    root             1     0   35864   1936 0                   0 S init
u:r:kernel:s0                  root             2     0       0      0 0                   0 S [kthreadd]
u:r:servicemanager:s0          system         522     1   12516   1760 0                   0 S servicemanager
u:r:hwservicemanager:s0        system         523     1 2127260   2524 0                   0 S hwservicemanager
u:r:vndservicemanager:s0       system         524     1   13024   1444 0                   0 S vndservicemanager
u:r:hal_hwfactoryinterface_de+ system         525     1   30988   2028 0                   0 S vendor.huawei.hardware.hwfactoryinterface@1.1-service
u:r:system_app:s0              system        1922   588 4292160  52416 0                   0 S com.huawei.powergenie
u:r:radio:s0                   radio         1942   588 4410860  60592 0                   0 S com.android.phone
u:r:platform_app:s0:c512,c768  u0_a68        1958   588 5578792 133612 0                   0 S com.huawei.android.launcher
u:r:kernel:s0                  root          1959     2       0      0 0                   0 S [kbase_event]
u:r:untrusted_app:s0:c155,c25+ u0_a155       2084   589 1954172  76736 0                   0 S com.UCMobile:push

（2）文件类（包含设备节点＼虚拟文件等）：ls命令带-Z，即显示安全上下文的标签。

1|HWRVL:/ $ ls -al -Z
drwxr-xr-x   2 root   root   u:object_r:radio_data_file:s0      0 2018-08-08 00:01 3rdmodem
drwxr-xr-x   2 root   root   u:object_r:radio_data_file:s0      0 2018-08-08 00:01 3rdmodemnvm
drwxr-xr-x   2 root   root   u:object_r:radio_data_file:s0      0 2018-08-08 00:01 3rdmodemnvmbkp
dr-xr-xr-x 105 root   root   u:object_r:cgroup:s0               0 2021-08-22 20:43 acct
lrw-r--r--   1 root   root   u:object_r:rootfs:s0              11 2018-08-08 00:01 bin -> /system/bin
lrw-r--r--   1 root   root   u:object_r:rootfs:s0              50 2018-08-08 00:01 bugreports -> /data/user_de/0/com.android.shell/files/bugreports
drwxrwx---   7 system cache  u:object_r:cache_file:s0        4096 2020-10-06 02:22 cache
lrw-r--r--   1 root   root   u:object_r:rootfs:s0              13 2018-08-08 00:01 charger -> /sbin/charger

策略Policy基础语法—描述访问规则

1、描述 谁 能对或者禁止对 什么类型的资源 进行 什么 操作权限；
语法如下：rule_variant source_types target_types : classes permissions

rule_variant：规则类型声明，包含allow允许， neverallow禁止，allowaudit记录，dontaudit失败不记录
source_types：访问主体对象的安全上下文type（或attribute），如进程的u:r:kernel:s0中的kernel；
target_types：访问客体对象的安全上下文type（或attribute），如文件的u:object_r:rootfs:s0中的rootfs；
classes：访问客体的类型中的具体类别，提示被访问的是什么东西，如file文件；
permissions：需要获取的权限，比如wrirte、read、ioctrl，这里可以是一些宏（包含一组权限，用来简化规则）
小技巧简化：
1）如果有多个source_type，target_type，class或perm_set，可以用”{}”括起来； 
2）~号，表示除了~以外；
3）-号，表示去除某项内容；
4）*号，表示所有内容

比如：
// 允许init域进程对shell_data_file,app_data_file类型字符文件，普通文件执行除了execmod execute relabelto以外的操作
allow init { shell_data_file app_data_file}:{ chr_file file } ~{execmod execute relabelto};
2、type/ attribute/ typeattribute声明命令，进行类型关联，描述谁的关系性；
语法如下：
type type_id [attribute_id][attribute_id] … // 表示定义把type，（并和一个到多个attribute关联）
attribute attr_id // 定义一个attribute属性，就是一组type的集合
typeattribute type_id attr_id // 把已经定义的type和 attribute进行关联

attribute就是一组type的集合，作为规则的执行对象。比如domain包含了一系列进程的type（init、debuggerd、kernel、system等）。有了attribute之后，可以将这些type与某个attribute关联起来，把这些type共有的权限，通过一条allow语句来设置attribute的属性，不需要每条type单独配置；

attribute attr_test;                # 声明attr_test属性
type t_a, attr_test;　　　　　　　　　# 定义t_a 类型 并关联 attr_test 属性
type t_b, attr_test;
allow attr_test t_c:file read;

策略制定相关文件—安全上下文定位contexts文件＼策略配置te文件

安全上下文通过文件的方式定义，不同的android版本存放的目录或者名称上有少量差异（往往 还会 分为google原生定义、vender供应商定义、平台的定义等）。例如默认android9.0上的配置文件，举例/system/sepolicy/private/
基本都分为以下几类：
１、file_contexts　文件安全上下文定义：

/(vendor|system/vendor)(/.*)?           u:object_r:vendor_file:s0
/(vendor|system/vendor)/bin/sh          u:object_r:vendor_shell_exec:s0
/(product|system/product)(/.*)?         u:object_r:system_file:s0 // 该目录下默认上下文为system_file
/dev(/.*)?              u:object_r:device:s0
/mnt            u:object_r:tmpfs:s0
/sys            u:object_r:sysfs:s0
/dev/binder             u:object_r:binder_device:s0
/dev/socket/netd                u:object_r:netd_socket:s0

2、service_contexts 服务安全上下文：

storaged                                  u:object_r:storaged_service:s0
storaged_pri                              u:object_r:storaged_service:s0
storagestats                              u:object_r:storagestats_service:s0
SurfaceFlinger                            u:object_r:surfaceflinger_service:s0
system_update                             u:object_r:system_update_service:s0
*                                         u:object_r:default_android_service:s0 // 任意取名默认权限

3、property_contexts 系统属性 安全上下文：（注意系统属性get时不会检测，set都会做mac检测）

sys.                    u:object_r:system_prop:s0
sys.cppreopt            u:object_r:cppreopt_prop:s0
log.                    u:object_r:log_prop:s0
log.tag                 u:object_r:log_tag_prop:s0
persist.audio.          u:object_r:audio_prop:s0
persist.bluetooth.      u:object_r:bluetooth_prop:s0
ro.vendor.config.hw_vowifi     u:object_r:vowifi_prop:s0
*                       u:object_r:default_prop:s0 // 任意取名默认权限

4、app安全上下文和seapp_contexts： 　（进程的安全上下文 可以通过静态设置 和 动态转换）
为app打标签，mac_permissions.xml根据apk签名设置app的seinfo，AndroidL只识别platform签名，其它都是default：

  <!-- Platform dev key in AOSP -->
  <signer signature="@PLATFORM" >
    <seinfo value="platform" />
  </signer>
  <!-- All other keys -->
  <default>
    <seinfo value="default" />
  </default>
  接下来seapp_contexts根据seinfo和user来为app打标签；
  user=system domain=system_app type=system_app_data_file
  user=bluetooth domain=bluetooth type=bluetooth_data_file
  … …
  # 三方的apk，如果有platform签名，则运行在platform_app域
  user=_app seinfo=platform domain=platform_app type=app_data_file
  # 三方的apk，如果没有platform签名，则运行在untrusted_app域
  user=_app domain=untrusted_app type=app_data_file

５、除了以上各类安全上下文定位的文件，剩下的.te文件就是策略文件*，部分举例如下：

# /system/sepolicy/private/adbd.te文件：
# adb pull /data/local/traces/*
allow adbd trace_data_file:dir r_dir_perms;
allow adbd trace_data_file:file r_file_perms;
# Run /system/bin/bu
allow adbd system_file:file rx_file_perms;
# /system/sepolicy/private/service.te 文件
type stats_service, service_manager_type;
type statscompanion_service, system_server_service, service_manager_type;
# /system/sepolicy/private/untrusted_app.te 文件：
typeattribute untrusted_app coredomain;
app_domain(untrusted_app)
untrusted_app_domain(untrusted_app)
net_domain(untrusted_app)
bluetooth_domain(untrusted_app)

三、Selinux问题定位

典型的MAC权限保报错日志：

一般通过 logcat | grep ‘avc|denied’ 关键字。或者在dmesg中搜索，类似如下：
<6>[12.435524] type=1400 audit(3635791.670:21): avc: denied { read write } for pid=273 comm=“mediaserver” name=“tfa98xx” dev=“tmpfs” ino=9770 scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 tclass=chr_file
表示： { read write } 一次读写权限被拒绝，主体的mediaserver这个进程，其安全上下文是u:r:mediaserver:s0，访问的客体安全上下文是u:object_r:device:s0，客体类型chr_file字符文件；

参考

android官方文档:：https://source.android.google.cn/security/selinux?hl=zh_cn
Android安全机制：https://www.kancloud.cn/alex_wsc/androids/472168
https://blog.csdn.net/qq_33750826/article/details/80743035
https://blog.csdn.net/paul_liao/article/details/50837873
https://www.jianshu.com/p/ba7c4e8cd699