移动应用安全之沙盒技术_沙箱技术可以做什么

前言

移动互联网的飞速发展, 改变了企业传统的业务模式, 提高了工作效率. 但同时也给企业的数据安全带来了巨大的挑战, 我们面对各种攻击的可能性会大 大增加, 面临潜在的风险:

• 移动设备中的不安全应用程序会危及到企业网络的安全；
• 移动设备可能在不安全的网络(如公共 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 (容器或沙盒) —— 应用级别的竖井，加密存储和传输状态的数据，对消息和应用数据提供隔离保护，设备其他部分无法访问。