前言
移动互联网的飞速发展, 改变了企业传统的业务模式, 提高了工作效率. 但同时也给企业的数据安全带来了巨大的挑战, 我们面对各种攻击的可能性会大 大增加, 面临潜在的风险:
移动设备中的不安全应用程序会危及到企业网络的安全;
移动设备可能在不安全的网络 (如公共 WiFi 热 点) 中使用, 容易造成恶意软件感染和数据泄漏;
越狱或获取 Root 权限移动设备会带更多风险;
移动设备被盗, 在未经授权的情况下访问公司的网络或者泄漏敏感数据.
企业移动应用安全平台由四部分功能组成, 安装在手机上的 安全容器, 安全加固 SDK, web 管理门户 和 通信代理, 各部分的功能及其相互间的关系如下所示:
Android 安全架构
Android 系统采用分层的体系结构, 分别为: Applications(核心应用程序),Application Framework(开发框架包),Libraries(系统运行库或者是 c/c++ 核心库),Hardware Abstraction Layer(硬件抽象层),Linux Kernel(Linux 内核).
Android 系统采用分层的系统架构进行设计, 每层都有其严格的安全规范和强健的安全架构. Android 的主要安全机制在内核层和系统框架层. 在系统框架层, Android 则采用了权限机制, 签名机制和沙箱机制, 来保护系统的安全, 隔离不同进程之间的资源访问, 授权访问系统资源和服务, 禁止非授权访问的发生.
权限机制是 Android 系统框架层提供的, 是对应用访问公共资源和服务进行强制访问的安全策略. 应用如果要使用公共资源和服务, 必须要在配置文件中声明需要使用对应资源的权限, 否则将无法得到授权, 致使不能使用其资源, 但是权限机制采用的全部肯定和全部否定的方式, 把最终的确定权交给了用户, 用户在不具备相关的安全知识的情况下是很难做出合适的判断的.
签名机制是应用中包含一个采用非对称加密方式存储的数字证书, 由于私钥在开发人员手中, 所以数字证书能够保证开发人员对其应用的合法拥有权. 虽然 Android 系统提供了签名机制来保护开发人员的合法拥有权, 但是并没有提供验证应用是否被恶意的二次重打包, 这使得应用被注入一些恶意的代码, 来获取非法的收益或达成恶意的目的.
沙箱虽然提供了进程隔离的机制, 保证运行时应用的进程空间不会被恶意的修改, 但是沙箱并没有在运行时验证是否运行环境是否安全, 是否系统的关键函数的地址发生了改变, 一旦系统的在进入沙箱前就已经被恶意修改, 沙箱中的应用也将受到恶意的威胁.
目前基于容器的 Android 加固方案和沙箱技术免安装应用的管理, 本质上都是基于 Android 系统插件化的技术, APK 沙箱需要解决以下几个问题:
VirtualApp 沙箱原理
VirtualApp 是一个开源的 Android App 虚拟化引擎, 允许在其中创建虚拟空间, 并在这个虚拟空间中运行其他应用. Android 应用隔离是基于 Linux 系统的多用户机制实现的, 即每个应用在安装时被分配了不同的 Linux 用户 uid/gid. 而在 VirtualApp 中, client 应用 (通过 VirtualApp 安装的应用) 与 host 应用 (即 VirtualApp 本身) 是具有相同用户 uid 的.
因此, VirtualApp 在运行时, 包含以下三部分:
Main Process, 进程名 io.virtualapp, 主要负责 VirtualApp 用户界面及应用管理
VA Server Process, 进程名 io.virtualapp:x, 主要负责系统服务的代理, 是通过 Content Provider 启动的
Client App Process, 进程名 io.virtualapp:p[0-...], 作为将来运行 client 应用的进程, 当 client 应用启动后, 其进程名会更新为 client 应用的包名
下面是在 VirtualApp 中运行应用后通过 ps 命令得到的结果:
各列参数意义:
USER: 进程当前用户;
PID: Process ID, 进程 ID;
PPID: Process Parent ID, 进程的父进程 ID;
VSIZE: Virtual Size, 进程的虚拟内存大小;
RSS: Resident Set Size, 实际驻留 "在内存中" 的内存大小;
WCHAN: 休眠进程在内核中的地址;
PC: Program Counter;
NAME: 进程名.
可以看到, 以上进程, 均是以 VirtualApp 的用户 uid 运行的. 因此, Android 应用隔离此时不再适用, 我们可以对 client 应用进行 hook 而无需 root 权限.
VirtualApp 源码结构
1. java/android: 覆盖了系统的隐藏类
content/pm/PackageParser: 主要对应 android.content.pm.PackageParser, 主要作用是解析 APK;
location/LocationRequest: 对应于 android.location.LocationRequest, 该类是一个可持久化的 Parcelable, 主要作用是设置 LocationManagerService 的参数.
2. com.lody.virtual: 框架的主体代码
client: 运行在客户端的代码, 指加载到 VA 中的子程序在被 VA 代理 (hook) 之后, 所运行的代码;
server: server 端代码, VA 伪造了一套 framework 层系统 service 的代码, 他在一个独立的服务中记录管理组件的各种 Recorder, 其逻辑其实与系统原生的相近, 通过 Binder 与 client 端的 ipc 包中的 VXXXXManager 通讯. 诸如 AMS(VAMS),PMS(VPMS);
remote: 一些可序列化 Model, 继承于 Parcelable;
os: 处理系统环境, 如多用户;
helper: 框架工具类.
3. mirror: 系统 framework 的镜像
实现了与 framework 层相对应的结构, 封装了反射获取系统隐藏字段和方法的, 便于直接调用获取或者赋值以及调用方法.
MAM 发展的现状
移动应用程序管理 (MAM) 背后的想法是我们将安全策略应用于单个应用程序而不是整个设备. 这意味着各种应用程序可以应用独特的策略, 并且无论设备的管理状态如何, 它们都将受到保护和管理. 基本的应用程序管理功能通常包括身份验证, VPN, 加密和远程擦除. 应用程序还连接到可以控制身份验证, 发出远程擦除命令或使用 IT 创建的策略控制应用程序的服务器.
前言部分我们我们知道沙箱技术主要用于企业应用管理的安全容器(安全桌面),MAM 中最关键的技术就是 APP Wrapping 和 Secure Container 部分, 它把一个移动设备划分出两个工作区, 从而实现个人空间与企业工作空间的隔离. 这些关键技术通俗理解就是 iOS,Android,WinPhone 上的应用虚拟化, 它没有一个标准接口可遵循, 完全靠各 MAM 厂商自己的技术功力来实现.
APP Wrapping (封装或者打包) -- 透过对应用封装打包或通过集成 SDK 方法, 控制服务和安全管理, 对于应用的分发, 访问和策略管理至关重要.
Secure container (容器或沙盒) -- 应用级别的竖井, 加密存储和传输状态的数据, 对消息和应用数据提供隔离保护, 设备其他部分无法访问.
来源: https://segmentfault.com/a/1190000015907234