Android安全策略SELinux
⽬录
SELinux原本是美国国安局联合⼀些公司设计的⼀个针对Linux的安全加强系统。
SELinux出现之前，Linux系统上的安全模型叫做DAC（⾃主访问控制），其原理是进程所拥有的权限与执⾏它的⽤户的权限相同（例如：以root⽤户启动Browser，那么Browser就有root⽤户的权限，在Linux系统上能⼲任何事情）。SELinux的出现结束了这种宽松的访问。 SELinux在DAC的基础之上，设计了新的安全模型叫做MAC（强制访问控制），其原理是任何进程想在SELinux系统中⼲任何事情，都必须先在安全策略配置⽂件中赋予权限，凡是没有在安全策略配置⽂件配置的权限，进程就没有该权限。Android4.4版本上正式推出的⼀套以SELinux为基础于核⼼的系统安全机制，且命名为SEAndroid，⾃此SELinux便被"移植"到了Android上了。
⼀、基本概念
1、⼯作模式
SELinux通常有如下三种模式：disable、permissive、enforcing。通常发布版都将使⽤强制模式Enforcing。
可以通过getenfoce来获取当前⼯作模式，还可以通过setenforce 0来设置当前模式为Permissive；也可以通过setenforce 1来设置当前模式为Enforcing。除此之外还可以进⼊fastboot模式设置：
#设置参数bootargs高斯玻取样
$setenv bootargs androidboot.selinux = permissive/enforcing
#保存参数
$saveenv
#重启系统
$reset
1）、关闭模式
如果SELinux 被关闭(开启Disable模式)，就使⽤传统的Linux系统默认的⾃主访问控制(DAC)⽅式，不需要增强安全性的环境来说，该模式是很好⽤的（换句话禁⽌SELinux功能）。
编辑配置⽂件/etc/selinux/config，把SELINUX=disabled，然后重启系统，SELinux 就被禁⽤了。
2）、宽容模式
在 Permissive 模式中，安全策略规则并没有被强制执⾏。当安全策略规则应该拒绝访问时，访问仍然被允许。然⽽，此时会向⽇志⽂件发送⼀条消息，表⽰该访问应该被拒绝（换句话使能SELinux功能，但是SELinux不会拒绝⽅法但会打印⽇志）。 SELinux Permissive 模式主要⽤于以下⼏种情况：审核当前的 SELinux 策略规则；测试新应⽤程序，看看将 SELinux 策略规则应⽤到这些程序时会有什么效果；解决某⼀特定服务或应⽤程序在 SELinux 下不再正常⼯作的故障。
3）、强制模式
Enforcing 模式， SELinux 被启动，并强制执⾏所有的安全策略规则（换句话使能SELinux，并强制按照SElinux的规则来进⾏权限访问）。
2、进程和资源
有⼈⽐喻Linux中有两种东西：死的（Inactive）、活的（Active）。活的东西就是进程，⽽死的东西就是资源（普通⽂件、特殊⽂件、套接字等）。他们之间就是⼀种使⽤（操作）与被使⽤（被操纵）的关系：进程能发起动作（例如它能打开⽂件并操作它）；⽽⽂件只能被进程操作。
SElinux Policy语⾔将死的和活的东西都给打上"标签"，通过"标签"将系统内的资源（包括进程）分成不同的⾓⾊（⽐如：⽤户、客体），进⽽对整个系统资(包括进程)进⾏合理安全的管控。 四合扣3、安全属性
在SELinux世界⾥，每种东西都会被赋予⼀个安全属性（官⽅说法叫Security Context，后⽂简称SContext），也可以理解为第⼀⼩节提到的标签。
Linux中的所有东西，包括活的进程、死的资源都有⾃⼰对应的SContext安全属性，因此可以把SContext分为进程SContext和资源SContext，⽆论哪种安全属性，他们的本质都是⼀个字符串，其格式如下：
user:role:type[:range]
#user表⽰⽤户：SEAndroid中仅定义了⼀个SELinux⽤户，⽤u表⽰
#role表⽰⾓⾊：可以暂时理解为在SELinux⽤户可以有多个不同的role，不同role所具有的权限也不⼀样
#type表⽰类型：不同的type所具有的权限也不⼀样，但跟role有本质的不同
#range表⽰安全级别：通常为s0，不⽤怎么关注
1）、进程SContext
HWBLN-H:/ $ ps -Z -A
LABEL USER PID PPID VSZ RSS WCHAN ADDR S NAME
u:r:init:s0 root 1 0 22180 1404 0 0 S init
u:r:kernel:s0 root 2 0 0 0 0 0 S [kthreadd]
u:r:kernel:s0 root 3 2 0 0 0 0 S [ksoftirqd/0]
u:r:kernel:s0 root 5 2 0 0 0 0 S [kworker/0:0H]
u:r:logd:s0 logd 405 1 20132 4168 0 0 S logd
u:r:servicemanager:s0 system 406 1 11320 808 0 0 S servicemanager
u:r:hwservicemanager:s0 system 407 1 14064 1532 0 0 S hwservicemanager
u:r:vndservicemanager:s0 system 408 1 10116 280 0 0 S vndservicemanager
u:r:hal_health_default:s0 system 473 1 12964 720 0 0 S android.hardware.health@1.0-service
u:r:hal_memtrack_default:s0 system 474 1 12988 772 0 0 S ack@1.0-service
u:r:hal_thermal_default:s0 system 475 1 13100 520 0 0 S android.hardware.thermal@1.0-service
u:r:hal_usb_default:s0 root 476 1 13044 556 0 0 S android.hardware.usb@1.0-service
u:r:displayeffect:s0 system 477 1 13128 516 0 0 S vendor.aphics.displayeffect@1.0-service
u:r:hal_audio_default:s0 audioserver 478 1 50088 2356 0 0 S vendor.huawei.hardware.audio@2.0-service
u:r:mediacommservice:s0 system 479 1 13140 532 0 0 S vendor.diacomm@2.0-service
u:r:hi110x_daemon:s0 system 480 1 16352 808 0 0 S vendor.huawei.hardware.hisupl@1.0-service
u:r:untrusted_app:s0:c512,c768 u0_a118 21453 684 4176436 310404 0 0 t.mm
点歌设备u:r:untrusted_app:s0:c512,c768 u0_a118 21473 684 3089252 57528 0 0 t.mm:push
u:r:untrusted_app:s0:c512,c768 u0_a118 21721 684 7797824 87584 0 0 t.mm:appbrand0
u:r:untrusted_app:s0:c512,c768 u0_a118 21737 684 7432960 42216 0 0 t.mm:appbrand1
输⼊命令ps -Z -A能够查询当前所有进程的安全属性，最右边列表⽰进程名称，最左边列表⽰该进程对应的安全属性。⼤多数的进程的SContext的user值为u表⽰SEAndroid⽤户；role值为r表⽰进程；ra
nge值为s0。
值得注意的是它们的type不⼀样，init进程的type值为init，进程logd的type值为logd，除此之外还有些进程的type是相同的，例如腾讯的⼏个进程的type都是untrusted_app。进程SContext的type字段代表该进程所属的Domain（域名），个⼈理解domain就跟tcp协议栈⾥⾯的域名⼀样，它对应于⼀类进程，后⽂将要讲解的安全策略就会应⽤于该类的所有进程，即相同type的进程具有相同的访问权限。
2）、资源SContext
#查看根⽬录的安全属性
1|HWBLN-H:/ $ ls -l -Z
drwxrwx--- 7 system cache u:object_r:cache_file:s0 4096 2020-04-30 14:34 cache
drwxrwx--x 57 system system u:object_r:system_data_file:s0 4096 2020-07-27 09:00 data
lrwxrwxrwx 1 root root u:object_r:rootfs:s0 23 1970-01-01 08:00 default.prop -> system/etc/prop.default
drwxr-xr-x 22 root root u:object_r:device:s0 3920 2020-07-27 09:00 dev
lrwxrwxrwx 1 root root u:object_r:rootfs:s0 11 1970-01-01 08:00 etc -> /system/etc
lrwxrwxrwx 1 root root u:object_r:rootfs:s0 8 2020-07-27 09:00 log -> /splash2
drwxr-xr-x 10 root system u:object_r:tmpfs:s0 240 2020-07-27 09:02 mnt
drwxr-xr-x 8 root root u:object_r:system_file:s0 4096 1970-01-01 08:00 odm
drwxr-xr-x 2 root root u:object_r:rootfs:s0 40 1970-01-01 08:00 oem
drwxr-xr-x 2 root root u:object_r:rootfs:s0 80 1970-01-01 08:00 res
drwx------ 2 root root u:object_r:rootfs:s0 40 2020-01-14 11:08 root
drwxr-x--- 2 root root u:object_r:rootfs:s0 420 1970-01-01 08:00 sbin
drwxr-xr-x 5 root root u:object_r:storage_file:s0 140 2020-07-27 09:02 storage
dr-xr-xr-x 14 root root u:object_r:sysfs:s0 0 2020-07-27 09:00 sys
drwxr-xr-x 22 root root u:object_r:system_file:s0 4096 1970-01-01 08:00 system
drwxr-xr-x 9 root root u:object_r:vendor_file:s0 4096 1970-01-01 08:00 vendor
在Android系统根⽬录执⾏ls -Z命令，能够查看根⽬录⽂件的SContext。⼤多数资源的SContext的user值为u代表SEAndroid⽤户；role值为object_r代表⽂件；range值为s0。
值得注意的他们的type不⼀样，⽬录cache的type值为cache_file；⽬录root和res和etc的type值为rootfs；⽬录system的type值为system_file；跟进程SContext⼀样，有些资源的type相同，代表他们是同⼀类，后⽂结束的allow语句配置的安全策略都将应⽤同type的资源。
#/system/bin⽬录下的安全属性
1|HWBLN-H:/ $ ls /system/bin/ -Z -l
-rwxr-xr-x 1 root shell u:object_r:system_file:s0 207 2020-01-14 11:39 am
lrwxr-xr-x 1 root shell u:object_r:zygote_exec:s0 13 2020-01-14 11:39 app_process -> app_process64
-rwxr-xr-x 1 root shell u:object_r:zygote_exec:s0 24988 2020-01-14 11:39 app_process32
-rwxr-xr-x 1 root shell u:object_r:zygote_exec:s0 23960 2020-01-14 11:39 app_process64
-rwxr-xr-x 1 root shell u:object_r:system_file:s0 194 2020-01-14 11:39 locksettings
lrwxr-xr-x 1 root shell u:object_r:system_file:s0 6 2020-01-14 11:39 log -> toybox
-rwxr-xr-x 1 root shell u:object_r:logcat_exec:s0 6840 2020-01-14 11:39 logcat
-rwxr-xr-x 1 root shell u:object_r:shell_exec:s0 298864 2020-01-14 11:39 sh
#/vendor/lib⽬录下的安全属性
1|HWBLN-H:/ $ ls /vendor/lib/ -l -Z
total 53600
-rw-r--r-- 1 root root u:object_r:vendor_file:s0 113284 2020-01-14 11:03 camera.device@1.0-impl.so
-rw-r--r-- 1 root root u:object_r:vendor_file:s0 159148 2020-01-14 11:03 camera.device@3.2-impl.so
-rw-r--r-- 1 root root u:object_r:vendor_file:s0 71608 2020-01-14 10:58 displayeffect.hi6250.s
o
空转锁drwxr-xr-x 2 root shell u:object_r:same_process_hal_file:s0 4096 2020-01-14 10:50 egl
drwxr-xr-x 2 root shell u:object_r:vendor_hal_file:s0 4096 2020-01-14 11:03 hw
drwxr-xr-x 2 root shell u:object_r:vendor_file:s0 4096 2020-01-14 11:03 hwcam
-rw-r--r-- 1 root root u:object_r:vendor_file:s0 53792 2020-01-14 10:58 libAntiTheftCA.so
-rw-r--r-- 1 root root u:object_r:vendor_file:s0 62704 2020-01-14 10:50 libBestShot.so
-rw-r--r-- 1 root root u:object_r:vendor_file:s0 16048 2020-01-14 10:58 libBootloaderOeminfo.so
如上⽂件/system/bin/log的type值为system_file，⽂件/system/bin/logcat的type值为logcat_exec，⽂件/system/bin/sh的type值为shell_exec。个⼈理解type后戳为file表⽰单纯的⽂件，后戳为exec代表它能够被执⾏，但是他们可不是天⽣就是这样的，具体详情后⽂将介绍。
4、TE术语
SEAndroid世界将所有事物都打上了标签（每个事物都有⾃⼰的SContext），那么SEAndroid就能根据这些SContext来进⾏统⼀管理。SEAndroid就是通过⼀系列的te⽂件来管理所有进程和资源的权限，每个te⽂件⾥⾯都有⽆数条te语句，每条te语句对应⼀条安全策略。
主体：主体和客体只是⼀个逻辑上的概念，就跟主谓宾语句：⼩红在吃⽶饭，其中主语是⼩红（活的），宾语是⽶饭（死的）。同理在Linux世界中，活的东西只有进程，死的东西是资源。即资源是被使⽤的东西，进程是使⽤者，这⾥的主体就是指使⽤者。SEAndroid 中的主体就是指的进程，当然可能是单⼀的进程，也可以是⼀组具有相同权限的进程，但是它们都对应⼀个type。
客体：同上客体就是这个被使⽤者。SEAndroid中的客体就是指的资源（包括普通⽂件/特殊⽂件/套接字），当然可能是单⼀的资源，也可以是⼀组相同类型的资源，但是他们都对应⼀个type。
客体类别：客体与客体类别的概念就类似于Java语⾔中的object和class，其中class表⽰⼀个类，object表⽰⼀个实例对象。同样客体和客体类别也是这样的关系，例如⼩红在吃⽶饭，⼩红在吃鱼⾁，⽶饭和鱼⾁都是具体的事物（客体），但是他们却是不⼀样的类别（客体类别）。SEAndroid中已经为资源定义了⼀些客体类别，我们也可以⾃定义。例如/etc/password是⼀个普通⽂
件，/atv/socket_0是⼀个套接字。
恒功率直流电源
访问许可：这个⽐较好理解，代表对客体的访问权限，例如读写权限，查询发送等权限。这个也是可以⾃定义的。
AV规则：既然已经有了主体和客体，那么就有对应访问规则，⼜叫AV规则。属于SElinux策略语⾔的控制部分，即te⽂件中每⼀条AV 规则语句都需要能够描述清楚：主体 对 客体 是否具有 访问许可。其实就是te⽂件⾥⾯的allow、neverallow、dontaudit、
auditallow等语句。
#⼀条完整的te安全控制语句格式应该为： AV规则主体客体：客体类别许可
#⽰例1：
allow netd proc:file write
#allow为AV规则，表⽰允许
#netd为主体，⼀般为进程SContext的type
#proc为客体，⼀般为资源SContext的type
#file为客体类别，表⽰proc是⼀个⽂件
#write为许可，表⽰写权限
#综上可以解读为：允许域名为netd的所有进程具有对资源⽂件proc的write权限
#⽰例2：
allow zygote init:process sigchld;
#allow为AV规则，表⽰允许
#zygote为主体
#init为客体，⼀般为资源SContext的type
#process为客体类别，表⽰init是⼀个进程
#sigchld为许可，表⽰发送信号
#综上可以解读为：允许zygote进程向init进程发送信号
5、allow语句
上节初步介绍了访问规则，在实际开发过程中，通常⽤的最多的还是allow语句，该语句格式如下：
allow 主体type 客体type 客体类别: {权限}
当SELinux拒绝访问权限的时候，将会打印如下⽇志：
avc:denied { map } for path="/data/local/data/mute.png" dev="mmcblk0p37" ino=5338 scontext=u:r:bootvideo:s0 tcontext=u:object_r:system_data_file:s0 tc 像这类⽇志都是以关键字avc开头，需要注意其中⼏个很重要的字段：
denied { 权限 }：到denied字段，后⾯通常跟随⼤括号，⾥⾯的内部就表⽰被拒绝的操作，即什么操作权限被拒绝，例如读写查等权限
scontext=主体上下⽂：到scontext字段，后⾯跟随的为主体安全上下⽂SContext，即代表主体进程
得到训练tcontext=客体上下⽂：到tcontext字段，后⾯跟随的为客体安全上下⽂SContext，即代表被访问单个资源或⼀系列资源的上下⽂tclass=客体类别：到tclass字段，后⾯为客体类别
通过上⾯⼏个关键字，我们就可以为其配置专门的AV规则，安装allow语句的规则可以在对应主体进程的te⽂件下添加allow语句：allow bootvideo system_data_file:file { map }
⼆、策略⽂件
这⾥不深⼊讲解SEAndroid相关的所有⽂件，也不讲解⼀些基本type和属性的⼀些定义，只需要明⽩android默认的策略配置都基本上写好了，这些策略配置基本上不需要我们去更改。但是⼚商定制策略⽂件的sepolicy⽬录下。这⾥介绍该⽬录下⼏个⽐较重要的⽂件。
1、sepolicy/
<⽂件主要定义了⼀些service（服务对应的进程）的type。即定义了中的service对应进程的SContext的type字段。这些type通常会继承于service_manager_type。如下：
type hitv_service, service_manager_type;
type bootvideo_service, service_manager_type;
type quickplay_service, service_manager_type;
type shen_service, service_manager_type;
2、sepolicy/system/private/service_contexts
前⽂定义了⼀些type，但是这些type并没有得到使⽤，service_contexts⽂件就是⽤来配置Service（四⼤组件之⼀）系统服务的安全属性SContext，其中使⽤⾥⾯定义的type（进程的type也叫域名Domain）。如下：
TVService u:object_r:tvservice_service:s0
hitvservice u:object_r:tvservice_service:s0
hirmservice u:object_r:tvservice_service:s0
bootvideo u:object_r:bootvideo_service:s0
quickplay u:object_r:quickplay_service:s0
shen u:object_r:shen_service:s0
3、sepolicy/
前⽂已经为将启动的进程做了安全属性的配置，那么可以在为每个进程做具体的安全策略，通常
每个⾃定义进程就会对应⼀个te ⽂件，编译系统打包过程中会⾃动将sepolicy⽬录下的配置拼接到原⽣SEAndroid中。这⾥拿⾃定义进程shen来举例，那么就需要创建⼀个⽂件来配置具体安全策略。如下：
type shen,coredomain,domain;
#定义shen，继承于coredomain和domain，将代表某⼀组进程的域名
type shen_exec,exec_type,file_type;
#定义shen_exec，继承于exec_type和file_type，将代表某⼀资源，继承了执⾏权限
init_domain_domain(shen)
#具体安全策略
allow 语句
neverallow 语句
4、sepolicy/vendor/file_contexts
前⽂配置了进程SContext，那么这⾥还需要配置资源SContext，如下：
#Devices
/dev/sockect/vold0 u:object_r:vold_sockect:s0
/dev/sockect/vold1 u:object_r:vold_sockect:s0
#System files
/system/bin/bootvideo u:object_r:bootvideo_exec:s0
/system/bin/quickplay u:object_r:quickplay_exec:s0
/system/bin/shen u:object_r:shen_exec:s0
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议