- 积分
- 305
贡献1469
飞刀577 FD
注册时间2015-12-21
在线时间51 小时

扫一扫,手机访问本帖 
|
硬件平台:飞凌嵌入式 OKT507-C开发板
, U5 W. [/ m# X% o" f% r 操作系统:Android10.0
8 V" r9 n; q4 J* ~# r) z) O( G( P/ }7 m" k ^
飞凌嵌入式 T507 开发板 Android系统版本为Android10.0,默认开启了SELinux。基于MAC访问控制模型的SElinux,可以更好地保护我们的Android系统, 比如限制系统服务的访问权限、控制应用对数据和系统日志的访问等措施,这样就降低了恶意软件的影响,并且可以防止因代码存在的缺陷而产生的对系统安全的影响。
$ p) L# _6 h2 q 从系统安全方面考虑,SELinux是保护神,但是从软件开发方面,SELinux就是一道牵绊,这是一把双刃剑。( a' a# T$ k) I' |
; g4 B6 ]# Q0 E" g% m9 i( X
比如我们开发应用或者增加系统服务的某些权限的时候,我们必须遵循SELinux的规则,给我们的应用设置对应的安全策略,否则我们的应用就不具备访问数据或者设备的权限。下面我们MAC访问控制模型开始,简单的梳理一下飞凌嵌入式 T507 开发板 Android的安全策略,以及自定义飞凌嵌入式 T507 开发板 Android安全策略的方法。/ g* l$ k- c! V3 o
访问控制模型DAC,MAC 访问控制是指控制对计算机或者网络中某个资源的访问。没有它,所有人都可以访问任何资源。有了访问控制,用户在获取实际访问资源或进行操作之前,必须通过识别、验证、授权。
$ T- x+ w0 ]9 x0 V/ Z$ {( U, D 自主访问控制(DAC: Discretionary Access Control)系统识别用户,根据被操作对象的权限的设置,来决定该用户对其拥有的操作权限,read、write、exec。拥有这个对象权限的用户,又可以将该权限分配给其他用户,此谓之“Discretionary”。缺陷就是对权限控制比较分散,不便于管理,比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。
6 I; H! Z0 @7 V0 }7 g 强制访问控制(MAC: Mandatory Access Control)MAC是为了弥补DAC权限控制过于分散的问题而诞生的。在MAC这种模型里,管理员管理访问控制。管理员制定策略,用户不能改变它。策略定义了哪个主体能访问哪个对象。这种访问控制模型可以增加安全级别,因为它基于策略,任何没有被显式授权的操作都不能执行。MAC被开发和实现在最重视保密的系统中,如军事系统。主体获得清楚的标记,对象得到分类标记,或称安全级别。" {3 q) J& y9 A g
基于MAC的SElinux 参考链接:https://source.android.google.cn/security/selinux, d. b) l% }& U( W0 | X) m; i
软件通常情况下必须以 Root 用户帐号的身份运行,才能向原始块设备写入数据。在基于 DAC 的传统 Linux 环境中,如果 Root 用户遭到入侵,攻击者便可以利用该用户身份向每个原始块设备写入数据。从 Android 4.3 起,SELinux 开始为传统的自主访问控制 (DAC) 环境提供强制访问控制 (MAC) 保护功能。作为 Android 安全模型的一部分,Android 使用安全增强型 Linux (SELinux) 对所有进程强制执行强制访问控制 (MAC),甚至包括以 Root/超级用户权限运行的进程(Linux 功能)。例如,可以使用 SELinux 为这些设备添加标签,以便被分配了 Root 权限的进程只能向相关政策中指定的设备写入数据。这样一来,该进程便无法重写特定原始块设备之外的数据和系统设置。借助 SELinux,Android 可以更好地保护和限制系统服务、控制对应用数据和系统日志的访问、降低恶意软件的影响,并保护用户免遭移动设备上的代码可能存在的缺陷的影响。7 }% X& z. |; l$ \# B" {
* [7 T, } R! Q7 k9 L
* } Q% ~ P* o 飞凌嵌入式 T507 开发板 Android系统版本为Android10,SELinux默认开启,即使获得了该系统的root权限,也只能向相关策略中指定的设备写入数据,从而更好地保护和限制系统服务,保障系统和数据的安全。3 [' V# t% O1 `! K
标签、规则和域 SELinux 依靠标签来匹配操作和策略。标签用于决定允许的事项。套接字、文件和进程在 SELinux 中都有标签。SELinux 在做决定时需参照两点:一是为这些对象分配的标签,二是定义这些对象如何交互的策略。6 H3 V- ~3 ~4 B% B6 t A
在 SELinux 中,标签采用以下形式:user:role:type:mls_level,其中 type 是访问决定的主要组成部分,可通过构成标签的其他组成部分进行修改。对象会映射到类,对每个类的不同访问类型由权限表示。
& ]5 m6 H% |( Y6 L& w# \- N 策略规则采用以下形式:allow domains types:classes permissions;,其中:' D! d$ a2 N, B. v0 n( X
& j0 ^" D$ n- U Domain - 一个进程或一组进程的标签。也称为域类型,因为它只是指进程的类型。
. d) W( S/ a/ t' c Type - 一个对象(例如,文件、套接字)或一组对象的标签。
5 B4 @% |+ \& G2 Z; i Class - 要访问的对象(例如,文件、套接字)的类型。Permission - 要执行的操作(例如,读取、写入)。$ \5 G. ]# v2 \8 @3 n
策略配置源文件 1、external/sepolicy) h7 D; k* A9 g) ]) L& L
这是独立于设备的配置,一般不能针对设备进行修改
1 l- a. j6 V8 D- k1 Y1 f" I5 o, U, b, l
2、device/<vendor>/<product>/sepolicy
, I6 `; ^, Q) _4 N2 X 这是特定于设备的配置,基于 BOARD_SEPOLICY_* 变量来选择对应平台的策略配置。- { P# X, X: u5 u _/ ?
2 h/ |/ f9 R7 B4 ~) D
以飞凌嵌入式 T507 开发板 为例,T507策略文件的路径如下:
9 I8 C S7 T8 \ OKT507-android-source/android$ ls device/softwinner/common/sepolicy/private vendor
, S9 J2 f# F! o$ }3 ? Type Enforcement (TE) 配置文件 .te 文件中保存了对应对象的域和类型定义、规则。通常每个域一个 .te 文件,例如installd.te。在 device.te、file.te 中声明了设备和文件类型。在某些文件(例如domain.te、app.te)中则存储着共享规则。9 m1 h. A; s e2 b3 r
' R3 D7 u! A% M7 B8 N7 x5 W
以飞凌嵌入式 T507 开发板 为例,T507 system_app的TE文件的路径如下:
4 a6 Q" D5 @( C device/softwinner/common/sepolicy/vendor/system_app.te5 L/ x1 L# Q1 K2 z
标签配置文件 1、file_contexts:文件安全上下文
' V: z5 c; J6 E5 E$ v- F 2、property_contexts:属性安全上下文; f A$ u+ c4 W/ F. Z+ \$ L
/ M- @: d6 j) g. S 以飞凌嵌入式 T507 开发板 为例,T507 安全上下文文件路径如下:2 N3 v8 G. z R$ P) A
device/softwinner/common/sepolicy/vendor/property_contexts2 M+ b* a5 k4 X% }6 q8 @3 O
device/softwinner/common/sepolicy/vendor/file_contexts
& c; L; G; |$ o. n SEAndroid app分类 SELinux(或SEAndroid)将app划分为主要三种类型(根据user不同,也有其他的domain类型):! J. w! H6 I& z7 I2 m/ ?# W
1)untrusted_app 第三方app,没有Android平台签名,没有system权限6 c" l- X9 @* v, U4 D
2)platform_app 有android平台签名,没有system权限9 Y; y) `' b/ o$ s5 V$ K% U
3)system_app 有android平台签名和system权限6 r3 o& Q4 o5 w
从上面划分,权限等级,理论上:untrusted_app < platform_app < system_app9 V; s& F' K) P7 ?3 \
APP的domain和type 查看seapp_contexts文件,APP的domain和type由user和seinfo两个参数决定9 F' v7 l# x+ q" q
system/sepolicy/private/seapp_contexts
6 J% H2 w/ C% f/ d! p) K& O1 Y isSystemServer=true domain=system_server_startup
+ R$ O2 L: H' B3 k N# k# ~7 o user=_app seinfo=platform name=com.android.traceur domain=traceur_app type=app_data_file levelFrom=all/ B' g8 j2 B# E3 c% v1 g0 n* }' N3 q* e
user=system seinfo=platform domain=system_app type=system_app_data_file
; U2 M) R0 l% ]5 v user=bluetooth seinfo=platform domain=bluetooth type=bluetooth_data_file
2 ]- o$ s" k2 o, c% J! ?4 T user=network_stack seinfo=network_stack domain=network_stack levelFrom=all
$ y/ z# h- J8 C9 F j type=radio_data_file4 A( v" ~. D1 k& X& _5 r- k
user=nfc seinfo=platform domain=nfc type=nfc_data_file
+ I; \* L* r5 L9 v: O* }$ l$ d. c0 G0 N user=secure_element seinfo=platform domain=secure_element levelFrom=all5 f% F2 c/ I; C7 j8 ^' z; j
user=radio seinfo=platform domain=radio type=radio_data_file& v* d0 }; R: ^" u. B5 [9 o/ {
user=shared_relro domain=shared_relro
: C" O1 h" u# Y1 q$ L3 q I/ K user=shell seinfo=platform domain=shell name=com.android.shell type=shell_data_file
9 o0 j: z9 I; n6 |/ C user=webview_zygote seinfo=webview_zygote domain=webview_zygote
2 m' r! \0 f {$ O3 X3 ~/ b user=_isolated domain=isolated_app levelFrom=al
- A5 Z8 r4 }" R8 |; l luser=_app seinfo=app_zygote domain=app_zygote levelFrom=all
- X2 b, I+ Z* M6 J% ~" F1 N user=_app seinfo=media domain=mediaprovider name=android.process.media type=app_data_file ; s/ {' m. D" w3 S
levelFrom=user$ T; W: n8 ]- i- o/ ^# ], z, g
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user
7 `3 y- D; Z) F% k user=_app isEphemeralApp=true domain=ephemeral_app type=app_data_file levelFrom=all
/ E7 R0 [$ Q! P( I8 e9 J0 x user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user
# |, z% ]* a/ k5 Z7 e7 U7 I" x user=_app minTargetSdkVersion=29 domain=untrusted_app type=app_data_file levelFrom=all& u$ e7 _/ u1 B" o& ~ ~
user=_app minTargetSdkVersion=28 domain=untrusted_app_27 type=app_data_file levelFrom=all
. V6 u' C$ {' y9 ] user=_app minTargetSdkVersion=26 domain=untrusted_app_27 type=app_data_file
Q1 f; M' W0 R1 A levelFrom=user8 [& K" E9 m$ J
user=_app domain=untrusted_app_25 type=app_data_file levelFrom=user8 B6 z0 _* m! C
user=_app minTargetSdkVersion=28 fromRunAs=true domain=runas_app levelFrom=all
- f- i6 \$ k% f3 ~ user=_app fromRunAs=true domain=runas_app levelFrom=user
; k2 e% k) n: t/ z user 参考链接:https://blog.csdn.net/huilin9960/article/details/81530568
% e9 i: P% V+ |! x0 w& O user可以理解为UID。android的UID和linux的UID根本是两回事,Linux的UID是用于针对多用户操作系统中用于区分用户的,而Android中的UID是用于系统进行权限管理的。参考链接中的文章对于uid的产生讲的很清楚。% p! S$ ^, G% C; N) h
seinfo 不同签名会创建对应的selinux上下文。- p! l8 h9 h' K& z. _7 E$ d
Android.mk
% `! w) d3 O1 O LOCAL_CERTIFICATE := platform) ^- o! @9 B3 Z3 g# {. O3 G# S! X
有platform签名,所以seinfo是platform。
1 p, d- N0 H, y2 W4 t LOCAL_CERTIFICATE作用 参考文档https://blog.csdn.net/hnlgzb/article/details/107823874
) T" r6 s1 \3 Y* F' w. F. S 可以查看Android源码build/target/product/security/ 目录下提供的默认签名文件,不同平台可能会有差异:飞凌嵌入式 T507 开发板 提供了media、networkstack、platform、shared、testkey、verity六种不同权限的签名文件。
1 r$ ^0 P* i/ l, K9 U 4 \+ g8 P# c- e+ Z
以飞凌嵌入式 T507 开发板 为例,查看当前运行的应用信息:; }7 K! C( B& n C2 O
console:/ # ps -Z
/ d. L4 J! U% M7 v- [: s; I u:r:system_app:s0 system 15712 1861 1050628 110868 SyS_epoll_wait ( C; Z) z9 A% H5 `# f
0 S forlinx.example.app, b1 R. u5 O$ h
u:r:untrusted_app_27:s0:c512,c768 u0_a62 30259 1861 1052120 114132 SyS_epoll_wait
# r; C% P$ X0 b) Z) _' X3 _ 0 S com.forlinx.changelogo& P, B9 t) }! \7 H% f4 U
当前运行的两个APP,forlinx.example.app的UID(user)是system,拥有platform签名,它的domain和type就是system_app。
! g9 v# x6 O( \1 ^ 3 _* A- X" s6 D! M
, y3 U* D3 |5 _0 I' F6 f+ G
" e+ k/ F& {0 K8 [- A com.forlinx.changelogo没有设置UID使用的默认设置,其UID为u0_a62,并且没有设置签名文件,它的domain和type就是untrusted_app。! Q# T- H5 o8 [ V# `1 w3 V, _
T507自定义安全策略 以上面两个运行的app来说,我们为这两个APP添加额外的权限,对应的TE配置文件分别就是system_app.te、untrusted_app.te,对应路径为:
) [4 S) ~2 u& l0 C device/softwinner/common/sepolicy/vendor/system_app.te
' y+ o' ]$ H# C: h* x; j4 o, p device/softwinner/common/sepolicy/vendor/untrusted_app.te
+ g! L" e" x5 q, u
( ~. y Q! J+ @ 以forlinx.example.app为例,我们为其添加can设备的执行权限:: @2 ?/ f5 w1 H- E/ m
7 [3 j+ v9 j) ~7 p" C1 D. n
OKT507-android-source/android$ vi device/softwinner/common/sepolicy/vendor/system_app.te
3 j% l/ O: J. ^/ [8 o ...
/ D, |3 T, R. Z! x allow system_app vendor_shell_exec:file { getattr open read execute execute_no_trans };
, ]5 v2 t2 P1 c1 x. E4 m% r7 d. t allow system_app shell_exec:file { getattr open read execute execute_no_trans };* m% ]" U& F6 c- h- R% `
allow system_app shell:file { getattr open read execute execute_no_trans };
$ r# W! r8 e n% y1 q ...9 ~' e* u' w7 _: W6 Y
以策略规则配置形式(allow domains types:classes permissions)! ^' R& U+ A" l3 c7 y A4 E
分析:domains:system_app6 r: ~/ N! ]. I7 t) L
types:vendor_shell_exec
7 Z A3 `2 _) o9 P% @ classes:file
4 }( E P8 g" b; w) E. D9 W7 J4 N permissions:getattr open read execute execute_no_trans& z6 J' R& Q% ]* o3 a
neverallow failures 有时我们增加的权限,系统默认的配置是不允许的,比如我们上面给forlinx.example.app增加的执行脚本的权限,报错如下:
; ~* U6 b3 O6 r O7 E; I S5 c3 I
3 Y7 c* ?4 s5 G2 ~! L8 g! A libsepol.report_failure: neverallow on line 9 of system/sepolicy/private/system_app.te
( M, d: q1 S; A (or line 41463 of policy.conf) violated by allow system_app shell:file { read open };$ }% @" v, A0 y5 Z6 y! N
libsepol.report_failure: neverallow on line 22 of system/sepolicy/private/shell.te) b' L* W W4 g: d1 W# Y2 v8 @; E; @
(or line 40025 of policy.conf) violated by allow system_app shell:file { read open };, e+ ^ b! T9 K L/ Q
libsepol.check_assertions: 2 neverallow failures occurred% ?+ Q0 |) h# d) Y: \5 M/ M4 l
0 S9 _: W. B( u# v3 R6 ^ | 系统默认的安全策略的路径为system/sepolicy/,根据报错的提示,我们可以修改默认的配置,修改system/sepolicy/private/system_app.te和system/sepolicy/private/shell.te,从而完成权限的赋予。
0 K$ Y" M) R7 ~: P$ j( \ a
0 \: i3 F5 {9 ]& Q2 B 以上就是Android 安全策略的脉络,以及飞凌嵌入式 T507 开发板 Android系统下自定义安全策略的方法了。- E+ N+ l/ [, _6 @4 s% n
+ ?5 b9 Q i: J |
|