Android安全三、移动平台安全机制

一、签名和授权

1、移动平台中的主流签名作用:自签名的完整性鉴别

自签名：证书的签名者和证书拥有者是同一实体。
自签名作用1：作为信任链的根证书。

1.png

自签名作用2：完整性鉴别。

2、移动平台中的主流签名作用:信任模式

不是自签名证书，采用信任模式。
可信任：由不同runtime平台决定app是否可信任。
如何鉴别可信任：通过签名，签名回溯（过期、颁发者位于系统可信任列表里）。
权利差异：把特权操作给与可信任应用。比如发短信。

3、移动平台中的主流签名作用:限制安装/运行

应用安装时：
是否包含签名？---》没有，矜持安装。
提取证书进行验证---》证书是有效且可信任的吗？----》不是，禁止安装。
基于证书的公钥对签名进行验证---》签名正确吗？---》不正确，禁止安装。

应用运行时：
是否包含签名？---》没有，禁止运行。
提取证书进行验证---》证书是有效且可信任的吗？----》不是，禁止运行。
基于证书的公钥对签名进行验证---》签名正确吗？---》不正确，禁止运行。

4、权限的作用：细粒度的特权管理

权限是一个ID或者一个字符串。
权限用来细分权利（雷瑟Capability）。
通常一个权限与一个操作绑定。
权限首先要申请。
申请后是否批准由平台策略决定。
比如：读写SDCard、Reset手机

5、权限的安全性保护：通过签名

权限的完整性保护：防篡改
例子（通过认证并获得签名后再加policy权限）

权限的授权安全策略：防Escalate
例子（普通应用申请Inject Event权限）需要手机厂家额私钥来签名才有某些特殊权限

二、Android中的签名

1、Android的签名作用：完整性鉴别

支持自签名用于完整性鉴别（无法验证APK是否是可信任的）
不做信任模式
不做安装和运行时的限制

2、Android的签名作用：Signature Permission和ShareUID

Signature Permission Level Permission
用于特权Permission
只有特定签名的Apk才被授权

2.png

Share Process UID
android：shareUserID="xxx（随便起）"
Process间Share UID的目的是共享资源等
Android 中两个Apk Share相同的UID必须其签名所用的Private Key一样。

3、Android的签名作用：身份ID 和升级的匹配

安卓中的自签名只是代表了身份，但不代表身份是否可信任。

Android的应用的Identifier是Package Name：
PAckage Name 不一样，相互不影响，允许同时存在（安装）；
Package Name一样，只能存在一个，允许做升级处理。

升级的安全性考虑：
必须签名的证书一致（防假冒。防侵入隐私）；
如果不一致，则哦用户要么放弃新的应用，要么卸载旧的，再安装新的，但这属于安装，不属于升级；
正常的升级将不擦除应用的工作目录数据，以保证历史数据的持续性。

4、Android APK 之META INF

APK 结构：

3.png

META INF组成：

4.png

签名流程：
java -jar signapk.jar testkey.x509.pem testkey.pk8 update.apk update-signed.apk

MANIFEST.MF

5.png

CERT.SF
对MANIFEST.MF加密

6.png

CERT.RSA

7.png

包含证书信息以及基于私钥的签名信息（CERT.SF）

三、Android中的权限一

1、Android的签名作用：细粒度特权管理

应用需要显示申请权限
用户对权限可知（不可控）
对特权权限单独控制

2、Android的不同权限类别

Normal（默认）、Dangerous（有提醒）、Signature（自己用）、SignatureOrSystem（系统也可以用）

3、Android的权限定义方式

定义在AndroidManifest.xml中：

8.png

4、Android的平台权限定义

在 frameworks/base/core/res/AndroidManifest.xml

9.png

四、Android中的权限二

1、Android 的运行时权限控制方式：通过PM的CheckPermission

Android独有的Service（底层平台Linux不具有）。所以需要在Android本身Framework中控制。
主流的Servide一般都基于Binder IPC或者其他IPC提供服务。
所以在最底层控制（Service所在的Service中）以避免逃逸控制。（绕开Utility Function 直接Invoke Remote Servide）

2、Android 的运行时权限控制方式：映射为OS的特定属性

非Androi特有的Service（底层平台已经提供，如FIle访问，TCPIP数据收发等）有多个访问入口访问：Android API ，JAVA API，NDK C API，Shell，etc。
底层控制准则，汇聚口在底层，所以在底层（OS层面）同一控制。这样可以避免逃逸控制。
所以复用OS的一些安全控制特性，比如GID。
所以需要把Android空间的Permission Mapping到OS的GID。

例子 访问SDCard（把权限mapping到os）

10.png

3、Android的permission与UID/GID的mapping

11.png 12.png

五、Android中的组件安全机制

1、Android的4大组件及组件间的通信

Android是基于组件的复用，组件间的边界透明。
组件间基于Intent通信。

2、组件的Public和Private

概念：public 系统里的其他组件都能和我通信；Private对完不可见，只能被当前组件所在的同一个进程访问，或者被Share同一个UID的访问。
由andorid：exported字段控制Public和Private。
Exported的default值：如果没有定义intent-filter则为false。即private。
Override default值：如果定义了intent-filter，也想exported=false也是可以的（相反也是同理可以的）

3、组件的Permission Assignment（组件间也不是随便就能通信的）

Securing Activities:(比如不想让别人启动activity，就定义一个permission）

13.png

必须有START_ACTIVITY1 Permission才能启动。

Securing Service（start or bind）（同理）:

14.png

只能控制start or bind

Securing ContentProvider:

15.png

Securing BroadcastReceiver:

16.png

六、android 中的应用安装（跟安全有关的）

1、应用安装的安全性考虑和调用方式

应用安装是一个高特权/风险操作，所以必须可知/可控。
主流实现方式：客户只能委派而不能直接操作。
调用安装传统模式：返送Intent给系统的Package Install app。
特权安装模式：系统的Package Install App内部会调用PackageManagerService的Install Package,该操作与android.permission.INSTALL_PACKAGES绑定，且该permission的protection level是signature|system

所谓的静默安装方式只存在ROOT手机上，开发者可以选择：基于pm cmd:pm install -r

17.png

2、应用安装流程之UID/GID的分配

18.png 19.png 20.png

3、应用安装流程之工作目录的创建和权限设置

21.png 22.png 23.png 24.png

七、Android中系统Service的安全

1、Binder的安全

Binder的作用：实现以IPC的RPC，完成远程业务范围。
Binder的CheckCallingUid

1.png 2.png

2、ServiceManager Add Service 的安全限制

Service Manager Process的作用：Naming Resolver，用于RPC框架中：AddService、GetService。
Add Service的安全限制：

3.png 4.png

3、Zygote的Process Fork

启动ApK流程：

5.png

进入SystemService，因为是第一个，所以需要创建一个Process：

6.png

Zygote 中进程执行：

7.png 8.png

4、Zygote的Socket安全检查

八、Android中的ContentProvider以及基于URI的安全

1、ContentProvider的作用：软件设计更加优美

屏蔽内部数据存储操作的差异性
对外提供一致的数据操作方式
抽象/共性===》都是数据操作

2、ContentProvider的作用：进程间数据共享

9.png

ContentProvider是运行在Service Process中的。通过Proxy和Binder调用ContentProvider

3、权限临时继承的需求

场景：用PDF Viewwe打开Email。
解决方式：临时委派使得委托者的权限临时提升（类似Root-setUID
模式）

4、配置ContentProvider允许临时委派权限

ContentProvider内部

10.png

5、基于URI的权限临时委派：基于API

在当前Client中：

11.png

6、基于URI的权限临时委派：基于Intent

12.png

九、Android的policy模式和多设备绑定

1、Android的Policy模式

安装时提问：

13.png

有以下特点：

14.png

2、MR2开始的AppOps

RunTime Permission Control：可知可控

15.png 16.png

3、AppOps对开发者的影响

17.png

4、应用于设备绑定的需求背景

计费应用下载：防导出运行

5、设备绑定

18.png

6、跨设备使用

19.png

十、应用内计费和App TO SDCard

1、什么事应用内计费

直接在应用内进行Payment以unLock某些功能，或者购买某些道具。

2、应用内计费的需求

可支付途径（信用卡，手机卡等）
安全性 ：面向用户 可知、可控
安全性：面向应用 可信（避免免费使用收费内容）

3、解决方案

20.png

4、Google IAP框图

21.png 22.png

5、SD卡上安装应用的安全策略：绑定设备

23.png 24.png 25.png 26.png

6、SD卡上安装应用的安全策略：ASEC的不可访问性

27.png 28.png

十二、Android中的多用户安全

1、需求场景

Android中与Windows/Linux区别：
UID/GID不跟着User走；
UID/GID和User的区分和绑定。

应用的可控共享：
共享，不存在多份的Code；
可控，控制谁可见。

数据的多用户独立：
工作目录；
External Storage。

2、UserManagerService

作用 ：
管理User的属性信息：设置/获取用户的UserID，Name，Icon,RestrictProfile等；
管理User:创建，删除等。

29.png

3、跟图学习

30.png 31.png 32.png 33.png 34.png 35.png

4、对开发者的影响

36.png

十三、Android SuperUser机制讲解

1、ROOT的作用

Customization
任何需要特权的操作

2、ROOT的第一步：寻找漏洞并安装特权文件

37.png

3、SU的sUID特性

38.png

Android 中的App授权获取Root权限，其实不是App自身的权限提升了，而是通过具有Root权限的sh流来执行shell命令。

4、MR2后的方案： SU Daemon Service

39.png 40.png

十四、SEAndroid

1、DAC和MAC

41.png

2、基于Label的MAC

42.png 43.png

3、运行框图（混合模式）

44.png

4、Apache的例子（Legacy and SELinux）

45.png 46.png

5、推荐读物

47.png

6、Permissive和Enforcement

48.png 49.png

7、SEPolicy文件结构

50.png 51.png