Android系统的安全问题 - 移动平台安全机制

1 签名和权限

1.1 什么是自签名

证书的签名者和证书拥有者是同一个实体。

1.2 自签名的作用

1. 作为信任链的根证书。
2. 完整性鉴别。

1.3 何为信任，如何鉴别信任？

签名了的，且CA认证了的。

1.4 可信任和普通应用的权利差异

人为的把一些Operation归类，某类Operation对于可信任应用和普通应用的表现是不一样的。

1. 应用安装时：

   是否包含签名—没有？禁止安装

   提取证书进行验证—证书是否有效且可信任—不是？禁止安装

   基于证书的公钥对签名验签—签名是否正确—不正确？禁止安装

2. 应用运行时：

   是否包含签名—没有？禁止运行

   提取证书进行验证—证书是否有效且可信任—不是？禁止运行

   基于证书的公钥对签名验签—签名是否正确—不正确？禁止运行

1.5 权限的作用：细粒度的特权管理（类似Capacity）

1. 权限是一个ID或一个字符串
2. 权限用来细分权利（类似Capacity）
3. 通常一个权限与一类操作绑定
4. 权限首先需要申请，申请后是否批准由平台策略决定

2 Android中的签名

2.1 Android的签名作用

1. 完整性鉴别
2. Signature Permission和ShareUID
3. 身份ID和升级匹配
   
   

2.2 Android APK之META INF

3 Android中的权限

3.1权限作用：细粒度特权管理

1. 权限与操作关联
2. 用户需要显式申请
3. 用户对权限可知
4. 对特权权限单独控制

3.2 权限类别

1. Normal
2. Dangerous（安装时提示用户）
3. Signature（其他应用想要使用本应用资源时要一样的签名才行）
4. SignatureOrSystem（申请权限的APP签名和定义此权限的APP签名一致 或者 申请权限的APP是系统应用）

3.3 如何确定要定义的类别

系统中对权限的定义在文件中：frameworks/base/core/res/AndroidManifest.xml

3.4 Android的运行时权限控制方式

• 通过PM的CheckPermission
• 映射为OS的特定属性

3.4.1 通过PM的CheckPermission【Android独有的Service（底层平台不具有）】

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

3.4.2 映射为OS的特定属性【非Android独有的Service（底层平台已经提供，如File访问、TCPIP数据收发等）】

多个入口访问:Android API,Java API,NDK C API，Shell ，etc。

底层控制准则，会聚口在底层，所以在底层(OS层面)统一控制，这样可以避免逃逸控制,所以复用OS的一些安全控制特性，比如GID。需要把Android空间的Permission Mapping到OS的GID。

4 Android中的组件安全机制

4.1 四大组件及组件间的通信

• 4大组件
• Android是基于组件的复用，组件间的边界透明（组件是否在同一个进程对编程者变得不可见了）
• 组件间基于Intent通信（弱化了CS架构，很多功能由系统服务来完成）

4.2 组件的Public和Private的概念

1. 组件的Public和Private的概念
   • 组件是Public：该组件希望系统内其他组件可以通过Intent/Binder与之通信
   • 组件是Private：该组件对外是不可见的，只能被当前进程内的其他组件通信
2. 控制组件是Public/Private的方式是配置：android:exported=true/false字段
   • exported的默认值(系统通过有没有为组件设置intent-filter来判断)
   • override的默认值(忽略系统默认exported的机制)

4.3 组件的Permission Assigment

5. Securing Activities（不想让任何人都能启动此Activity，需要有它定的权限才行）

   

6. Securing Services（不想让任何人都能start/bind此Service，需要有它定的权限才行，如果想为Service中的每个API加权限需要像3.4.1节说的那样定义）

   

7. Securing ContentProvider
   

8. Securing BroadcastReceiver
   

5 Android中应用安装

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

1. 应用安装是一个高特权、高风险操作，必须可知可控。(让用户看得见且可操作)

2. 主流实现方式：客户只能委派而不能直接操作。

3. 调用安装的传统模式：发生Intent给系统的PackageInstaller APP

   

4. 特权安装模式：系统PackageInstaller APP内部调用PMS的Install Package，该操作与android.permission.INSTALL_PACKAGES绑定，且该Permission的protection level是SignatureOrSystem

5. 所谓的静默安装方式只存在ROOT手机上，开发者可以选择：pm install xxx

5.2 应用安装流程之UID、GID分配

pms+installd

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

installd代为操作

6 Android系统Service的安全

6.1 Binder的安全

6.2 ServiceManager Add Service的安全限制

6.3 Zygete的Process Fork

如果是首次启动应用，第一个Activity

进入到AMS里的startActivity中会，调用Process.start去启动这个app的进程，再通过startviaZygote让Zygote来Fork这个进程。zygote再放权至这个应用的uid gid。

6.4 Zygote的Socket安全检查

• 任何一个进程都可以通过链接Zygote的socket让他fork一个进程吗？
• 会不会有一个进程给zygote的socket发信息让他修改启动应用进程的uid gid呢？

在Zygote的runOnce中会对远端进行Policy审查

比如applyUidSecurityPolicy方法，对远端的uid进行审查，若是root/system/other分别区分。

7 Android中的ContentProvider以及基于uri的安全

7.1 ContentProvider的作用：软件设计更优美

1. 屏蔽内部数据存储操作的差异性
2. 对外提供一致的数据操作方式
3. 抽象/共性 --> 都是数据操作

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

7.3 权限临时继承的需求

7.4 临时委派权限

7.4.1 配置ContentProvider允许临时委派权限

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

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

权限的生命周期：Activity Start --> Destroy 即Activity的生命周期。

问题：后台线程中访问ContentProvider的隐患。

8 Android的Policy模式和多设备绑定

8.1 Android的Policy模式

8.2 MR2开始的AppOps

8.3 AppOps对开发者的影响

8.4 应用与设备绑定的需求背景

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

8.5 设备绑定

8.6 跨设备使用

9 应用内计费和App2SDCard

9.1 应用内计费

9.2 App2SDCard

将App安装到SDCard，高版本Android为了安全已经移除此功能，不允许将APP安装到外存。

10 Android中的多用户安全

看视频就行，了解即可，手机很少有多用户的情况。

11 Android SuperUser机制

值得注意的是这里：

12 SEAndroid

12.1 DAC和MAC

12.2 基于Label的MAC

12.3 运行框图（混合模式）

12.4 Apache的例子（Legacy and SELinux）

12.5 推荐读物

• http://opensource.com/business/13/11/selinux-policy-guide
  使用猫粮，狗粮做比喻的讲解，非常生动有趣

• 《SELinux实例:使用安全增强的Linux》

  非常详细，对Policy文件的语法讲解很深入

12.5 Permissive和Enforcement Mode

12.6 SEPolicy文件结构

12.6.1 主体

可查看Android源码目录system/sepolicy/public

1. 先拿一个zygot.te举例子，其在te文件定义了两个type（zygote zygote_exec）,并且对应地关联了属性domain、exec_type、file_type
   

2. 关于属性domain、exec_type、file_type可以在system/sepolicy/public/attribute文件中找到。(这些属性存在的意义在于可以为一组type定义policy，以domain属性为例
   ：其关联所有的type，在设置某个文件要让所有type都允许对其访问时，就可以用domain来代表所有type了，不需要一个一个type去加权限)
   

3. 打开domain.te文件看看，其为所有关联了domain属性的type都配置了如下的policy

   

12.6.2 客体

可查看Android源码目录system/sepolicy/private/file_contexts文件

客体（文件）的type：

• lmage打包时确定:基于File Contexts
• 运行时创建则默认继承父Folder的Type
• 运行时Type Transition

12.6.3 宏

可查看Android源码目录system/sepolicy/public/te_macros文件

可复用的宏定义，相当于函数复用

12.7 例子

12,7.1 一个假想的需求

1. 实现一个Camera_d的Native Service，并在Init.rc中启动它
2. 权衡Policy:
   • 不定义dedicated的Domain Type?则会复用Init Domain Type
   • 后期一系列的policy需求都需要加到Init.TE中?
   • 不!! 这些Policy是Camer_d独有的，不该影响所有Init Type的Process Domain
   • 权限分离管理!

12,7.2 定义TE，设置Domain Transition

注意此时并没加入任何allow的policy

12,7.3 修改File Contexts

12,7.4 以Permissive模式编译

12,7.5 Check Runtime Subject and Object Type

12,7.6 Check AVC Message

12,7.7 修正Policy

12,7.8 Review Policy

• Audit2allow基于最大权限保证功能
• 软件安全策略:最小权限保证功能
• 所以，需要Review，并Repeat